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Abstract 

This  thesis  examines  techniques  to  automate  configuration  of  an  intrusion  de¬ 
tection  system  utilizing  hardware-assisted  virtualization.  These  techniques  are  used 
to  detect  the  version  of  a  running  guest  operating  system,  automatically  configure 
version-specific  operating  system  information  needed  by  the  introspection  library, 
and  to  locate  and  monitor  important  operating  system  data  structures.  This  re¬ 
search  simplifies  introspection  library  configuration  and  is  a  step  toward  operating 
system  independent  introspection. 

An  operating  system  detection  algorithm  and  Windows  virtual  machine  system 
service  dispatch  table  monitor  are  implemented  using  the  Xen  hypervisor  and  a  mod¬ 
ified  version  of  the  XenAccess  library.  All  detection  and  monitoring  is  implemented 
from  the  Xen  management  domain.  Results  of  the  operating  system  detection  are 
used  to  initialize  the  XenAccess  library.  Library  initialization  time  and  kernel  symbol 
retrieval  are  compared  to  the  standard  library.  The  algorithm  is  evaluated  using  nine 
versions  of  the  Windows  operating  system.  The  system  service  dispatch  table  monitor 
is  evaluated  using  the  Agony  and  ProAgent  rootkits. 

The  automation  techniques  successfully  detect  the  operating  system  and  system 
service  dispatch  table  hooks  for  the  nine  Windows  versions  tested.  The  modified 
XenAccess  library  exhibits  an  average  initialization  speedup  of  1.9.  Kernel  symbol 
lookup  is  10  times  faster,  on  average.  The  hook  detector  is  able  to  detect  all  hooks 
used  by  both  rookits. 
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Automated  Virtual  Machine  Introspection 
for  Host-Based  Intrusion  Detection 

I.  Introduction 

1 . 1  Motivation 

The  privilege  level  structure  of  computer  hardware  and  software  creates  a  battle 
between  malware  writers  and  security  researchers  for  control  of  the  system.  Programs 
with  higher  privileges,  whether  malicious  or  not,  have  visibility  into  and  can  control 
programs  with  lower  privileges.  Typically  the  programs  that  run  at  the  highest  privi¬ 
lege  level  are  the  operating  system  (OS)  kernel  and  its  components.  Malware  exploit¬ 
ing  the  kernel  or  its  components  can  gain  access  to  this  level.  Once  the  malware  is 
running  at  the  highest  privilege  level  it  can  modify  data  and  mask  its  presence  from 
the  kernel.  The  introduction  of  hardware-assisted  virtualization  technology  provides 
yet  another  level  for  malware  and  security  software  to  contend  for. 

Hardware-assisted  virtualization  (HAV)  technology  introduces  a  new  highest 
level  in  the  privilege  hierarchy.  This  level  is  more  privileged  than  the  operating 
system  kernel  and  any  kernel-mode  malware  that  might  infect  it.  This  advantage 
can  be  used  to  develop  a  secure  monitor  to  detect  malware.  This  new  level  in  the 
privilege  hierarchy  also  introduces  its  own  set  of  challenges.  The  separation  and 
isolation  provided  by  HAV  creates  a  “semantic  gap’:  that  makes  it  difficult  interpret 
the  memory  of  lower  privilege  levels  [CN01]. 

Bridging  the  semantic  gap  requires  detailed  knowledge  of  the  OS  structure.  For 
closed-source  operating  systems,  this  information  can  be  difficult  to  obtain  and  may 
change  with  patches,  updates,  or  new  versions.  One  method  of  bridging  the  semantic 
gap,  virtual  machine  introspection,  is  implemented  by  the  XenAccess  library  [PCL07]. 
The  library  requires  detailed  OS  knowledge  via  a  configuration  hie  and  system  map 
hie.  Additionally,  it  must  scan  memory  to  locate  the  base  address  of  the  kernel.  This 
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research  aims  to  streamline  XenAccess  library  configuration  and  use  it  to  implement 
secure  monitoring  for  operating  system  data  structures  using  HAV. 

1.2  Goals 

Configuring  of  a  virtualization-based  security  monitor  for  several  different  op¬ 
erating  systems  can  be  difficult  and  tedious.  Version-specific  information  must  be 
obtained  and  cataloged  for  each  operating  system  version.  The  goal  of  this  research 
is  to  automatically  configure  the  XenAccess  library  and  use  it  to  monitor  specific  OS 
data  structures  from  the  Xen  management  domain.  In  order  to  achieve  this  goal,  the 
following  obstacles  must  be  overcome: 

•  Detect  the  Guest  Operating  System 

•  Identify  Version- Specific  Offsets 

•  Locate  OS  Data  Structures  to  Be  Monitored 

The  ideal  solution  to  this  goal  would  be  a  security  application  that  can  monitor  any 
operating  system  and  automatically  monitor  any  important  data  structure.  To  limit 
the  scope  of  the  problem,  this  research  concentrates  on  the  Windows  operating  system 
as  it  has  an  88.7%  operating  system  market  share  [App08].  Moreover,  only  support 
for  monitoring  the  system  service  dispatch  table  is  implemented  because  it  is  exploited 
in  approximately  50  percent  of  malware  attacks  [KS07,  Ric06].  Techniques  used  by 
forensic  researchers  and  malware  writers  are  used  to  overcome  these  obstacles. 

1.3  Thesis  Layout 

This  chapter  introduces  the  research  motivation  and  goals.  Chapter  2  discusses 
relevant  research  accomplished  by  others  and  background  information.  Chapter  3 
describes  the  methodology  for  the  experiments  conducted  for  this  research.  Chapter 
4  discusses  experimental  results  and  analyzes  their  outcomes.  Finally,  Chapter  5 
provides  a  concluding  discussion  of  this  research  and  gives  recommendations  for  future 
work. 
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II.  Background  Research 

This  chapter  introduces  research  accomplished  by  others  and  fundamental  concepts 
relevant  to  virtualization,  host-based  intrusion  detection,  and  operating  systems. 
First,  Section  2.1  describes  and  compares  several  virtualization  methods.  Section  2.2 
details  important  Windows  operating  system  data  structures.  Section  2.3  defines  mal¬ 
ware  and  discusses  their  methods.  Sections  2.4  and  2.5  present  software  and  hardware 
host-based  intrusion  detection  system  technologies.  Section  2.6  explores  the  topic  of 
virtual  machine  introspection. 

2. 1  Virtualization 

Virtualization  provides  an  additional  layer  of  abstraction  beyond  the  Intel  4- 
ring  protection  model  shown  in  Figure  2.1  [Cor08a].  In  the  Intel  protection  model, 
ring  0  is  the  most  privileged  level  and  is  typically  where  the  operating  system  kernel 
resides.  User-level  applications  usually  run  at  level  three,  the  least  privileged  level. 
As  shown  in  Figure  2.2,  the  new  layer  provided  by  virtualization  resides  below  ring 
0  and  therefore  at  a  higher  privilege  level.  This  new  level  interacts  directly  with 
hardware  while  providing  an  interface  to  ring  0  that  is  nearly  indistinguishable  from 
the  standard  hardware  interface.  This  interface  is  implemented  in  a  virtual  machine 
monitor  (VMM),  or  hypervisor.  These  can  be  complex  programs  that  perform  many 
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Figure  2.2:  Virtualization  Protection  Model 


functions  to  interact  with  hardware  and  the  OS  or  very  lightweight  with  minimal 
functionality  and  less  chance  for  exploitable  software  bugs  [Rut08]. 

The  addition  of  the  VMM  layer  increases  security  by  isolating  the  operating 
system  within  a  virtual  machine  (VM).  This  separation  also  allows  for  the  VMM  to 
run  multiple  VMs  at  the  same  time  while  keeping  them  isolated  from  each  other. 
The  VMM  controls  what  each  operating  system  is  allowed  to  access  and  arbitrates 
any  interaction  between  them.  Server  virtualization  is  becoming  increasingly  popular 
because  of  this  ability  to  consolidate  several  software  services  onto  a  single  hardware 
system.  The  following  paragraphs,  discuss  the  different  types  of  virtualization  and 
their  tradeoffs. 

2.1.1  Paravirtualization.  Paravirtualization  requires  modifying  operating 
system  source  code  to  replace  privileged  function  calls  with  appropriate  substitutes 
that  result  in  a  call  to  the  VMM.  This  technique  allows  for  the  most  flexibility  because 
any  potentially  unsecure  calls  or  instructions  can  be  redirected.  Moreover,  additional 
functionality,  such  as  VMM  to  OS  communication,  can  be  added  as  necessary.  The  use 
of  paravirtualization  requires  modification  to  the  guest  operating  system  because  the 
VMM  does  not  reproduce  the  full  functionality  of  the  underlying  hardware  [BDF+03]. 
The  major  benefit  of  a  paravirtualization  is  that  because  the  OS  must  be  modified,  the 
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system  can  be  designed  to  increase  performance  and  to  bridge  the  “semantic  gap”  by 
providing  explicit  information  to  the  VMM  which  is  identical  to  that  within  the  OS. 
Jones  calls  this  “the  gold  standard  of  OS  information  within  a  VMM,”  but  cautions 
that  this  is  not  a  secure  means  of  obtaining  OS  information  because  a  compromised 
OS  can  report  false  information  [JADAD06]. 

2.1.2  Binary  Translation.  Binary  translation  is  used  by  commercial  virtual¬ 
ization  products  from  VMWare.  Unlike  paravirtualization,  the  operating  system  code 
does  not  have  to  be  modified  to  cooperate  with  the  hypervisor.  Virtual  CPU  state  is 
maintained  separately  from  physical  CPU  state.  When  translating  the  binary  instruc¬ 
tions,  the  translator  can  intercept  privileged  instructions  and  replace  them  with  the 
appropriate  instruction  referencing  virtual  data  structures,  but  allows  non-privileged 
instructions  to  execute  unmodified.  In  addition  to  privileged  instructions,  Adams  and 
Agesen  list  three  other  instruction  types  that  need  to  be  translated  to  maintain  con¬ 
trol  of  the  guest  operating  system.  These  include  program  counter  relative  addressing, 
direct  control  flow,  and  indirect  control  flow  [AA06].  These  instruction  types  must 
have  their  branch  targets  translated  to  the  correct  address. 

The  translation  process  is  efficient  because  the  majority  of  code  does  not  need 
to  be  modified  and  can  be  sent  to  the  processor  as  is.  The  amount  of  overhead  is 
dependent  on  how  many  instructions  need  to  be  translated  to  a  different  instruction(s). 
Adams  and  Agesen  measure  the  slowdown  caused  by  a  software  VMM  using  binary 
translation  and  a  hardware-assisted  virtualization  VMM  relative  to  native  execution. 
When  executing  the  SPECint  2000  benchmark,  the  software  VMM  and  hardware- 
assisted  VMMs  have  an  average  slowdown  of  4%  and  5%  respectively  [AA06].  SPECint 
2000  is  largely  user-level  code  and  therefore  only  incurs  a  small  overhead.  Adams  and 
Agesen  also  developed  seven  “virtualization  nanobenchmarks”  to  measure  overhead 
caused  by  instructions  or  sequences  of  instructions  that  require  VMM  intervention. 
Figure  2.3  compares  native,  software  VMM,  and  hardware-assisted  VMM  execution 
time  of  the  seven  benchmarks.  In  Figure  2.3  the  number  of  execution  cycles  for  native, 
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software  VMM,  and  hardware-assisted  VMM  execution  are  represented  by  gray,  white, 
and  black  respectively.  Overall,  the  software  VMM  using  binary  translation  executes 
slower  than  native,  but  is  faster  for  two  of  the  nanobenchmarks  due  to  a  more  efficient 
process  than  with  native  execution. 

2.1.3  Hardware- Assisted  Virtualization.  While  software  designers  have  de¬ 
veloped  very  capable  suites  for  virtualization,  many  have  been  developed  with  an 
emphasis  on  performance  and  consolidation  and  do  not  necessarily  concentrate  on 
security.  This  section  discusses  hardware  that  has  evolved  from  the  lessons  learned 
and  shortfalls  of  software  virtualization.  Intel  and  Advanced  Micro  Devices  (AMD) 
have  extended  their  x86  architectures  with  hardware  virtualization  instructions.  The 
hardware  extensions  from  both  manufacturers  eliminate  the  need  for  the  techniques 
used  by  software  virtualization,  such  as  binary  translation  and  paravirtualization.  In 
contrast  to  software  virtualization  where  either  the  VMM  must  intercept  instructions 
or  the  operating  system  must  be  modified  to  deprivelcge  privileged  instructions,  with 
Intel  Virtualization  Technology  (VT)  and  AMD  Secure  Virtual  Machine  (SVM)  the 
instructions  are  intercepted  by  hardware. 

2. 1.3.1  Intel  Virtualization  Technology.  The  Intel  VT  architecture  is 
based  on  virtual  machine  extensions  (VMX)  that  introduce  ten  VMX  instructions  to 
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Figure  2.4:  VM  Guest  Interaction  Life  Cycle  [Cor08a] 


the  Intel  32-bit  instruction  set  [Cor08b].  With  VMX,  two  new  CPU  modes  are  defoied- 
VMX  root  and  VMX  non- root.  The  intent  of  the  designers  is  for  the  VMM  to  run  at 
VMX  root  and  for  guest  operating  systems  to  run  at  VMX  non- root.  Additionally, 
in  both  VMX  root  and  VMX  non-root,  the  processor  can  run  in  any  of  the  four 
privilege  levels,  but  they  are  independent  of  each  other.  Ring  0  in  VMX  non-root 
is  less  privileged  than  Ring  0  in  VMX  root,  and  any  privilege  level  changes  in  VMX 
non-root  mode  may  cause  a  VM  exit  for  servicing  by  the  VMM. 

VMX  is  enabled  or  disabled  using  the  VMXON  or  VMXOFF  instructions  as 
illustrated  by  the  VMM  life  cycle  shown  in  Figure  2.4  [Cor08b],  After  VMX  mode 
is  enabled,  the  processor  transitions  from  root  to  non-root  mode  during  virtual  ma¬ 
chine  entry  and  exits.  The  VM  can  make  service  calls  to  the  VMM  via  the  VMCALL 
instruction,  causing  a  VM  exit.  Execution  in  VMX  non- root  mode  and  VMX  transi¬ 
tions  are  governed  by  the  virtual-machine  control  structure  (VMCS)  until  the  VMM 
issues  a  VMXOFF  instruction.  The  VMCS  is  referenced  with  a  physical  address  for 
efficiency  and  contains  six  logical  sections  of  control  data  for  the  VM  [UNR+05].  The 
sections  are  guest  state,  host  state,  VM-execution  control,  VM-exit  control,  VM-entry 
control,  and  VM-exit  information  [Cor08b],  The  VMCS  can  be  read  and  written  to 
using  the  VMREAD  and  VMWRITE  instructions. 

The  guest  state  section  of  the  VMCS  contains  register  state  and  non-register 
state  values:  Activity  State,  Interruptibility  State,  Pending  debug  exceptions,  and 
the  VMCS  link  pointer.  Guest  state  information  is  loaded  from  the  guest  state  sec- 
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tion  on  every  VM  entry  and  saved  for  VM  exits  [Cor08b].  The  host  state  section 
contains  specific  register  values  to  restore  the  state  of  the  processor  whenever  a  VM 
exit  transitions  the  processor  back  to  VMX  root  mode  [Cor08b],  The  VM-execution 
control  section  details  how  interrupts  and  exceptions  should  be  handled.  In  addi¬ 
tion.  it  contains  several  bitmaps  that  define  what  should  and  should  not  cause  a  VM 
exit  [UNR+05].  The  VM-entry  and  VM-exit  control  sections  of  the  VMCS  define 
the  basic  operation  of  VM  entry  and  exits.  Finally,  the  VM-exit  information  section 
contains  information  about  the  most  recent  VM  exit,  such  as  the  reason  for  exiting. 

2. 1.3. 2  AMD  Secure  Virtual  Machine.  The  AMD  SVM  is  very  sim¬ 
ilar  to  Intel’s  VT.  SVM  provides  a  set  of  hardware  extensions  for  virtualization  and 
security.  The  parallel  to  VT’s  root  and  non-root  mode  is  host  and  guest  mode  in 
AMD’s  SVM.  Also,  AMD’s  documentation  refers  to  VM  entry  and  VM  exit  as  world 
switching  [AMD08] .  The  processor  enters  guest  mode  by  executing  a  VMRUN. 

SVM  defines  a  Virtual  Machine  Control  Block  similar  to  VT’s  VMCS  that 
regulates  how  each  VM  functions.  The  VMCB  is  a  fixed  length  of  2,564  bytes  and 
contains  control  and  state  information  for  the  associated  VM  [MY07].  The  VMCB 
can  be  modified  using  the  VMSAVE  and  VMLOAD  instructions.  The  control  section 
contains  the  intercept  vector  which  tells  which  instructions  will  cause  a  ^VMEXIT 
as  well  as  rules  for  interrupts  and  exceptions.  The  state  section  of  the  VMCB  stores 
register  contents  and  other  state  information  for  the  guest  VM.  Finally,  like  VT, 
an  EXITCODE  is  stored  telling  the  VMM  why  the  guest  caused  an  exit  to  host 
mode  [AMD08]. 

2.1.4  Xen  Virtual  Machine  Monitor.  Xen  is  a  virtual  machine  monitor 
that  originated  from  the  XenoServers  project  at  the  University  of  Cambridge  [vH08]. 
The  initial  public  release  of  Xen,  version  1.0,  is  a  paravirtualization-only  VMM.  Xen 
contains  a  management  domain  0,  or  domO,  that  relieves  the  VMM  of  high  level 
VM  management  tasks  and  controls  “their  associated  scheduling  parameters,  physical 
memory  allocations  and  the  access  they  are  given  to  the  machine’s  physical  disks  and 


network  devices.”  [BDF+03]  Xen  paravirtualized  guest  OSes  must  be  modified  such 
that  all  interaction  with  hardware  is  conducted  through  the  VMM.  Device  drivers  are 
replaced  with  Xeno-Aware  drivers  that  interface  the  VMM  and  privileged  instructions 
within  the  OS  are  paravirtualized  with  calls  to  the  Xen  hypervisor.  The  cost  of  making 
these  changes  to  the  guest  OSes  is  2,996  and  4,620  lines  of  code  for  Linux  and  Windows 
respectively  [BDF+03]. 

With  the  release  of  Xen  3.0,  hardware  virtualization  instructions  are  supported. 
This  allows  Xen  to  run  unmodified  operating  systems  reducing  the  overhead  of  par- 
avirtualization  and  enabling  the  use  of  closed-source  OSes.  Hardware-assisted  vir¬ 
tualization  is  accomplished  by  running  the  Xen  VMM  in  VMX  root  mode  and  the 
guest  OS  in  VMX  non-root  mode.  Instructions  that  were  paravirtualized  previously 
will  cause  a  VM-exit  to  the  VMM  when  executed  by  a  guest  OS.  Additionally,  the 
VMM  emulates  devices  for  the  guest  OS  so  that  specialized  Xen  device  drivers  are 
not  necessary  [PFH+05]. 

Figure  2.5  demonstrates  the  capabilities  of  the  Xen  3.0  architecture.  Domain  0 
is  the  trusted  domain  handling  communication  between  the  hypervisor  and  untrusted 
VMs.  It  contains  native  device  drivers  with  direct  access  to  hardware.  VM  1  is  a 
trusted  VM  that  has  been  given  special  access  to  the  hardware  via  the  hypervisor. 
VM  2  is  a  symmetric  multiprocessor  paravirtualized  guest  OS  that  has  been  modified 
to  work  with  the  Xen  hypervisor.  Finally,  VM  3  is  an  unmodified  Windows  XP 
operating  system  using  HAV.  The  arrows  demonstrate  how  the  domain  0  and  trusted 
VM  1  arbitrate  communication  with  the  hardware  for  the  other  VMs. 

In  the  6  years  since  Xen  1.0  was  released  it  has  become  a  popular  virtualization 
platform.  It  is  used  by  thousands  in  both  academia  and  the  commercial  sectors  [vH08]. 
Commercial  versions  exist  that  provide  virtualization  solutions  to  corporations,  but 
the  Xen  project  is  still  an  open  source  venture  supported  by  programmers  from  over 
20  well  known  information  technology  corporations  [CS09] .  The  availability  of  source 
code  makes  Xen  an  attractive  choice  for  research. 
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Domain  0  VM 1  VM  2  VM  3 


Figure  2.5:  Xen  3.0  Architecture  [ADC05] 


2.2  Windows  Data  Structures 

Operating  systems  contain  many  important  data  structures  that  directly  control 
execution  and  are  therefore  targets  for  malicious  code.  In  order  to  protect  them,  their 
function  must  be  thoroughly  understood.  The  following  sections  describe  the  structure 
and  function  of  Windows  OS  data  structures  commonly  exploited  by  malware. 

2.2.1  Microsoft  Portable  Executable  and  Common  Object  File  Format.  The 
Microsoft  Portable  Executable  (PE)  and  Common  Object  File  Format  (COFF)  is 
used  by  executable  hies,  dynamic  link  libraries  (DLL),  and  device  drivers  for  Win¬ 
dows  operating  systems  [Cor08d].  Files  that  follow  this  specification  have  a  defined 
structure  that  can  be  used  to  interpret  them  both  on  disk  and  in  memory.  Figure  2.6 
presents  the  specified  structure  of  a  PE  hie  with  a  memory  dump  of  the  hrst  656  bytes 
of  the  Windows  XP  Service  Pack  2  kernel  executable  for  illustration.  The  base  of  the 
image  header  begins  with  the  hex  bytes  0x4d5a,  or  “MZ”  in  ascii.  Additionally,  the 
PE  header  offset,  highlighted  in  white  with  the  value  0xe8,  is  always  located  at  0x3c 
and  points  to  the  location  of  the  PE  header  further  in  the  hie.  A  valid  PE  image 
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Figure  2.6:  Windows  XP  SP2  Dump  &  PE  File  Format 


begins  the  PE  header  with  the  4-byte  signature  of  “PE\0\0”,  as  seen  in  the  first  four 
bytes  of  the  middle  box.  The  PE  header  contains  machine  type  information,  section 
information,  symbol  information,  size  of  the  optional  header,  and  hie  attribute  hag 
information.  Windows  executables  also  contain  an  optional  header  appended  to  the 
PE  header.  The  optional  header  begins  with  the  “magic”  hexadecimal  number  0x10b 
for  a  PE32  executable,  such  as  ntoskrnl.exe.  The  information  of  interest  in  the 
optional  header  is  the  data  directory  information.  This  gives  the  location  and  size  of 
tables  used  by  the  image  during  execution.  The  resource  table  is  of  specihc  interest 
for  identifying  the  operating  system  version  [Car07].  Additionally,  the  export  table 
contains  names  and  pointers  to  all  of  the  functions  exported  by  the  image. 

Following  the  PE  header  are  the  section  headers,  in  the  bottom  and  lightest 
gray  box,  containing  name,  size,  and  location  information  for  each  section  contained 
in  the  hie.  The  resource  and  export  table  addresses  are  duplicated  in  section  headers 
and  can  be  compared  to  those  from  the  data  directory  for  integrity. 
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2.2.2  System  Service  Dispatch  Table.  The  system  service  dispatch  table 
(SSDT)  is  used  to  hold  addresses  of  Windows  system  call  functions  in  order  for  the 
system  service  dispatcher  to  find  and  execute  system  services  belonging  to  the  kernel, 
Ntoskrnl.exe.  Additionally,  a  shadow  SSDT  exists  that  holds  addresses  of  Win¬ 
dows  window  manager  and  graphics  device  interface  (GDI)  services  exported  from 
Win32k.sys  [RS04],  Figure  2.7  illustrates  how  a  Windows  system  call  is  made  from 
an  application.  The  application  calls  the  Kernel32.dll  function,  WriteFile,  which 
calls  the  Windows  specific  Ntdll.dll  subsystem  function,  NtWriteFile.  Next,  a  soft¬ 
ware  interrupt  is  generated  using  the  SYSENTER  or  SYSCALL  instruction  on  Intel  or 
AMD  architecture,  respectively.1  This  prompts  a  transition  to  kernel  mode  where 
the  service  number  argument  passed  from  above  is  translated  into  the  address  of  the 
Ntoskrnl.exe  version  of  NtWriteFile  using  the  SSDT.  Finally,  the  NtWriteFile  pro¬ 
cesses  the  service  request  and  the  call  is  complete.  The  right  side  of  Figure  2.7  depicts 
a  call  to  a  GDI  or  window  manager  service  and  is  similar  to  a  kernel  dispatch  except 
that  it  does  not  involve  Kernel32.dll  because  Win32k.sys  is  inherently  Windows 
specific.  Also,  the  shadow  SSDT  is  used  to  look  up  the  service  function.  The  struc¬ 
ture  of  this  process  makes  it  vulnerable  to  attack  and  is  discussed  in  further  detail  in 
Section  2. 3. 2. 2. 

2.2.3  Process  and  Thread  Lists.  Processes  and  threads  in  Windows  are 
represented  by  data  structures  called  executive  process  and  thread  blocks,  referred  to 
as  _EPR0CESS  and  _ETHREAD  in  the  kernel  debugger.  These  structures  contain  infor¬ 
mation  about  each  process  or  thread  and  pointers  to  other  necessary  data  structures. 
These  structures  are  linked  together  in  memory  by  pointers  called  the  Sink  and  blink. 
Once  a  single  process  block  is  found,  the  list  of  processes  can  be  traversed  to  enumer¬ 
ate  all  running  processes  on  the  system.  Figure  2.8  shows  how  the  lists  are  connected 
and  related.  The  ThreadListEntry  field  of  each  process  points  to  its  list  of  threads. 
Detailed  information  about  the  _EPR0CESS  structure  is  contained  in  Appendix  B. 

1INT  0x2e  is  used  on  processors  prior  to  the  Pentium  II 
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Figure  2.7:  System  Service  Dispatching  [RS04] 


Figure  2.8:  Process  and  Thread  Lists 
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2.3  Malware 


One  major  benefit  of  using  virtualization  for  intrusion  detection  is  that,  except¬ 
ing  a  flaw  in  the  VMM  itself,  it  isolates  the  VMM  from  malware  running  on  a  guest 
OS.  The  mechanisms  in  the  hardware  that  control  transitions  from  root  to  non- root 
provide  an  isolated  execution  environment  for  each  VM  that  is  running  on  the  host 
system.  Any  communication  in  or  out  of  an  individual  VM  is  handled  by  the  VMM 
and  subject  to  its  controls.  In  order  to  understand  the  vulnerabilities  of  operating 
systems  it  is  necessary  to  understand  the  different  types  of  malware  and  methods  used 
by  malware  to  infect  an  operating  system. 

Figure  2.9  shows  an  adaptation  of  Rutkowska’s  malware  taxonomy  [Rut06].  The 
figure  shows  the  four  different  types  of  malware  and  where  they  reside  with  respect 
to  other  common  memory  structures.  The  large  boxes  represent  processes  with  the 
largest  one  at  the  top  being  the  system  process,  or  kernel.  The  gray  boxes  represent 
the  code  and  data  sections  of  each  process  in  memory  with  arrows  representing  hooks 
planted  by  malware  to  jump  to  the  malware  code.  Hooking  and  its  different  imple¬ 
mentation  methods  are  discussed  in  Section  2.3.2.  The  black  boxes  represent  malware 
and  are  classified  based  on  their  location. 

Type  0  malware  is  a  malicious  program;  acting  on  its  own  without  help  from 
or  modification  to  the  operating  system  or  other  processes.  Type  I  malware  modifies 
the  static  code  sections  of  processes  or  the  operating  system,  whereas  type  II  malware 
modifies  dynamic  data  sections.  Finally,  type  III  malware  is  introduced  as  malware 
that  resides  outside  of  any  process  or  the  operating  system’s  memory  space  [Rut06]. 
Malware  Types  0,  I,  and  II  may  be  able  to  detect  a  VMM  [GAWF07],  but  are  not 
allowed  to  affect  the  VMM  because  of  hardware  protections  that  cause  a  VM  exit  and 
return  control  to  the  VMM.  However,  type  III  malware  can  affect  the  VMM  by  modi¬ 
fying  the  system  BIOS  or  exploiting  a  bug  in  the  VMM.  Some  type  III  malware  exists, 
such  as  Bluepill  and  Vitriol  [Rut07b,  Zov06],  but  the  millions  of  malware  signatures 
that  commercial  antivirus  programs  use  are  for  Type  0,  I,  or  II  malware  [Sym08]. 
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Type  0 
Malware 


Figure  2.9:  Malware  Taxonomy  adapted  from  Rutkowska  [Rut06] 


This  means  a  VMM-based  intrusion  detection  system  is  protected  by  hardware  from 
most  types  of  malware  and  can  potentially  detect  malware  of  types  0,  I,  and  II. 

2.3.1  Rootkits.  Rutkowska’s  taxonomy  classifies  malware  based  on  where 
they  reside  in  the  system  whereas  Skoudis  [SZ03]  takes  a  more  functional  approach 
dividing  them  into  8  categories  based  on  function.  Among  those  categories  are  user- 
level  and  kernel-level  rootkits.  Rootkits  can  be  classified  as  type  I  or  type  II  malware. 
Skoudis  defines  them  as  “Trojan  horse  backdoor  tools  that  modify  existing  operating 
system  software  so  that  an  attacker  can  keep  access  to  and  hide  on  a  machine.”  [SZ03] 
In  other  words,  the  user-level  or  kernel-level  components  that  are  used  to  carry  out 
basic  operating  system  functions  are  modified  by  rootkits  for  malicious  purposes. 
Hooking  and  Direct  Kernel  Object  Manipulation  (DKOM)  are  used  by  rootkits  to 
alter  operating  system  function  and  are  discussed  in  the  following  sections. 
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2.3.2  Hooking.  One  method  that  rootkits  rely  on  to  ensure  their  code  is 
executed  is  by  using  hooks.  In  short,  hooks  are  redirections  of  execution  caused  by 
replacing  an  address  or  piece  of  code  within  a  process’  memory  space  or  an  operating 
system  data  structure.  Hooks  can  either  be  in  user  space  or  kernel  space  and  allow  a 
malicious  piece  of  code  to  alter  what  is  seen  by  the  user. 

2.3.2. 1  User  or  Application  Programming  Interface  Hooks.  Applica¬ 
tion  Programming  Interface  (API)  hooks,  though  easier  to  detect  than  kernel  hooks 
because  they  do  not  run  in  ring  0,  can  be  useful.  In  order  for  malicious  code  to  install 
API  hooks,  it  must  first  have  access  to  the  process’  memory  space.  This  is  typically 
accomplished  using  code  or  DLL  injection  [HB05].  Once  attached  to  the  process, 
the  malicious  code  can  modify  the  import  address  table  (IAT),  export  address  table 
(EAT),  or  install  inline  function  hooks  as  described  below: 

•  IAT  and  EAT  Hooks 

As  described  in  the  Microsoft  PE  and  COFF  specification,  Windows  executables 
and  libraries  must  contain  import  and  export  information  so  that  functions  can 
be  shared  between  them.  At  load  time,  any  libraries  that  functions  are  being 
imported  from  are  loaded  into  the  process’  memory  along  with  the  executable. 
During  this  process,  the  IAT  of  the  executable  is  also  loaded  with  the  appro¬ 
priate  addresses  for  each  imported  library  function.  IAT  and  EAT  hooking  is 
accomplished  by  modifying  the  tables  that  hold  the  addresses  of  these  imported 
or  exported  functions.  When  a  hooked  imported  function  is  called,  execution 
will  be  redirected  to  the  hook  function  instead  of  the  actual  library  function. 

•  Inline  Hooks 

Inline  function  hooking  works  by  overwriting  the  first  five  bytes  of  a  victim 
function  with  a  jump  to  the  address  of  the  rootkit  code.  This  is  possible  because 
most  Windows  functions  after  Windows  XP  SP2  contain  a  common  five-byte 
preamble.  The  process  is  slightly  more  difficult  with  versions  before  SP2  that 
only  contain  a  three-byte  preamble,  but  still  possible  by  simply  saving  and 
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Figure  2.10:  A  User-Space  Inline  Hook  Example  [Rie06] 


overwriting  the  two  bytes  following  the  preamble  [HB05].  Listing  II.  1  shows  the 
code  bytes  and  assembly  commands  they  represent  for  both  preambles. 

Listing  II.l: 


;  SP2 

and  Later 

Pre - SP2 

8bf  f 

mov  edi  , 

edi 

55 

push  ebp 

55 

push  ebp 

8bec 

mov  ebp ,  esp 

8bec 

mov  ebp  , 

esp 

The  five  bytes  that  are  overwritten  are  saved  and  become  part  of  a  trampoline 
function  that  allows  the  victim  function  to  execute  and  then  returns  execution  to 
the  rootkit  code.  At  this  time,  the  rootkit  can  modify  the  results  returned  by  the 
victim  function  before  they  are  returned  to  the  calling  application.  Figure  2.10 
gives  a  visual  representation  of  the  process. 

2. 3. 2. 2  Kernel  Hooks. 

•  System  Service  Dispatch  Table  Hooks 

SSDT  hooking  replaces  the  address  of  the  system  call  functions  in  the  SSDT 
with  addresses  pointing  to  a  hook  function.  Figure  2.11  shows  how  a  SSDT  hook 
intercepts  execution  and  is  able  to  filter  data  returned  by  the  system  call.  The 
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Figure  2.11:  System  Service  Dispatch  Table  [RS04] 


system  service  dispatcher  uses  the  table  to  look  up  the  appropriate  system  call 
address  which  has  been  replaced  by  a  hook  function  address.  The  hook  function 
can  then  call  the  real  system  service  and  filter  results  or  simply  return  anything 
to  the  calling  function.  SSDT  hooking  is  similar  to  IAT  or  EAT  hooking  in 
user-space  except  that  the  SSDT  is  a  read-only  kernel  data  structure.  In  order 
to  modify  values  in  the  SSDT  the  rootkit  has  to  bypass  memory  protections 
placed  on  the  table.  This  can  be  done  by  clearing  bit  sixteen,  the  write  protect 
bit,  of  the  CRO  register  or  by  creating  a  memory  descriptor  list  with  flags  that 
allow  writing  to  the  region  containing  the  SSDT  [HB05].  In  addition  to  their 
use  by  malware,  SSDT  hooks  are  used  by  many  personal  security  products  to 
enable  operating  system  monitoring. 

•  Interrupt  Descriptor  Table  (IDT)  Hooks 

As  mentioned  in  Section  2.2.2,  system  calls  on  legacy  hardware  generate  a  soft¬ 
ware  interrupt  via  the  I  NT  0x2e  instruction.  Handling  this  interrupt  requires 
looking  at  entry  0x2e  in  the  IDT  for  the  address  of  that  interrupt  handler. 
Therefore,  replacing  the  IDT  entry  at  0x2e  with  the  address  of  a  hook  function 
causes  that  function  to  run  whenever  any  system  call  is  made.  Figure  2.7  can 
be  used  to  illustrate  the  effect  of  an  IDT  hook.  An  IDT  hook  causes  execution 
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to  be  redirected  during  the  software  interrupt  preventing  KiSystemService,  the 
real  INT  0x2e  handler  from  being  called.  Each  CPU  in  a  system  maintains 
an  IDT  and  the  address  can  be  found  by  executing  the  SIDT  instruction.  Any 
entry  in  the  IDT  can  be  replaced  allowing  an  attacker  to  intercept  execution  for 
events  such  as  page  faults  in  addition  to  system  calls.  One  drawback  to  using 
IDT  hooks  is  that  execution  does  not  return  to  the  interrupt  handler.  In  the 
case  of  hooking  0x2e,  this  means  that  execution  does  not  return  to  the  hook 
function  and  that  it  cannot  be  used  for  modifying  data,  only  blocking  it. 

•  SYSENTER  Hooks 

On  Pentium  II  processors  and  above,  the  SYSENTER  instruction  is  used  to  execute 
a  fast  system  call.  SYSENTER  redirects  execution  to  the  address  contained  in  the 
Model  Specihc  Register  (MSR),  IA32_SYSENTER_EIP  [Cor08c].  An  attacker  can 
read  and  write  the  value  in  this  register  from  ring  0  using  the  RDMSR  and  WRMSR 
instructions.  This  enables  an  attacker  that  has  obtained  access  to  ring  0  to 
redirect  execution  to  any  arbitrary  address. 

•  Input/Output  Request  Packet  (IRP)  Function  Table  Hooks 

When  a  driver  is  loaded,  a  table  containing  the  addresses  of  all  the  functions  it 
uses  to  handle  IRPs  is  initialized.  IRPs  hold  information  needed  by  the  system 
to  process  I/O  requests.  A  rootkit  can  replace  entries  in  the  IRP  function  table 
and  control  the  results  of  these  I/O  requests.  This  hooking  method  is  useful  for 
intercepting  network  traffic  as  demonstrated  by  Hoglund  [HB05]. 

2.3.3  Direct  Kernel  Object  Manipulation.  Using  DKOM  a  rootkit  can  affect 
some  of  the  same  changes  made  by  altering  execution  with  hooking.  DKOM  relies  on 
precise  information  about  important  operating  system  data  structures.  The  Windows 
process  list  described  in  Section  2.2.3  is  one  example  of  a  kernel  object  that  is  vul¬ 
nerable  to  DKOM.  A  rootkit  can  use  DKOM  to  change  the  Flink  and  Blink  pointers 
in  this  list  such  that  certain  processes  are  unlinked  from  the  list  and  will  be  hidden. 
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Additionally,  DKOM  can  be  used  to  hide  device  drivers,  hide  ports,  elevate  privileges 
and  skew  forensics  [HB05]. 

2-4  Software  Host-Based  Intrusion  Detection 

The  basic  intrusion  detection  system  (IDS)  needs  three  components  to  function 
properly.  The  system  first  needs  to  use  some  sort  of  sensor  to  collect  data.  Second, 
the  system  has  to  classify  or  determine  if  the  data  obtained  exhibits  malicious  activity. 
Finally,  it  needs  to  act  on  that  determination  and  report  an  intrusion.  These  apply  to 
all  types  of  intrusion  detection  systems  regardless  of  their  design.  Intrusion  detection 
systems  can  be  distributed  or  contained  on  a  single  machine,  with  the  latter  being 
the  more  prevalent  [HFS98].  Network  intrusion  detection  systems  (NIDS)  are  used  to 
monitor  network  traffic  between  multiple  computers  while  host-based  intrusion  detec¬ 
tion  systems  (HIDS)  monitor  multiple  data  on  one  specific  machine,  such  as  network 
traffic,  operating  system  data  structures,  or  system  calls.  This  research  focuses  on 
host-based  intrusion  detection  because  of  the  advantages  that  can  be  afforded  to  it 
by  virtualization. 

2-4-1  Data  Collection.  When  collecting  data  one  must  first  determine  what 
data  is  beneficial  for  intrusion  detection.  There  has  been  much  research  on  using 
system  call  traces  as  indicators  of  intrusion  [HFS98,  SYfZ+05,  FS08,  YA04,  YXS+05, 
WD01].  System  calls  run  at  the  highest  privilege  level  in  the  kernel  and  therefore 
are  a  desirable  target  for  attackers  that  want  to  gain  privileged  access  to  the  system. 
System  call  monitoring  simply  observes  the  flow  of  system  calls.  In  contrast,  with 
system  call  interposition,  execution  can  be  redirected  based  on  some  criteria.  For  the 
purposes  of  this  discussion,  system  call  interposition  and  system  call  monitoring  are 
used  interchangeably  because  many  of  the  same  collection  techniques  apply  whether 
interposing  or  simply  monitoring  the  flow  of  system  calls. 

Several  methods  exist  to  intercept  system  calls.  Utrace,  strace,  and  the  built- 
in  ptrace  are  all  Linux  tools  that  can  be  used  to  capture  system  calls  [McGb,McGa]. 
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System  call  monitoring  or  interposition  has  also  been  implemented  as  a  loadable  Linux 
kernel  module  with  Janus,  BlueBox,  and  Systrace  [Gar03,CC03,Pro03]. 

While  system  call  interposition  provides  a  useful  indication  of  intrusion,  it  is  also 
susceptible  to  mimicry  and  concurrency  attacks  [Pro03,  Wat07].  Additionally,  most 
research  abstracts  away  the  difficulty  and  overhead  of  interposing  on  system  calls; 
these  are  discussed  in  more  detail  in  Section  2.4.3.  In  addition  to  system  calls,  other 
OS  data  structures  like  those  discussed  in  Section  2.2  along  with  files,  directories, 
processes,  and  kernel-level  modules  can  also  be  useful  [JWX07]. 

2-4-2  Data  Classification.  Once  data  is  obtained  it  needs  to  be  classi¬ 
fied  as  malicious  or  normal.  This  problem  is  the  center  of  much  research,  though 
there  are  basically  two  techniques:  signature-based  (misuse-based)  classification  and 
anomaly-based  classification.  Signature-based  classification  requires  the  construction 
of  a  database  of  known  malicious  signatures.  Anomaly-based  classification  establishes 
a  baseline  of  behavior  that  is  considered  normal  and  uses  statistical  analysis  to  detect 
when  behavior  deviates  from  normal. 

Signature-based  detection  is  commonly  used  for  antivirus  software  and  net¬ 
work  intrusion  detection.  These  programs  require  significant  maintenance  to  keep  up 
with  the  release  of  hundreds  of  exploits  and  vulnerabilities  released  monthly  [Sec08] . 
Symantec  Antivirus  contains  definitions  for  1,854,843  threats  and  risks  [Sym08],  and 
Snort,  a  popular  open-source  NIDS,  has  a  database  of  approximately  13,000  rules  for 
detecting  intrusions  [Sou], 

A  large  body  of  research  has  been  directed  toward  anomaly-based  systems. 
Hofmeyr,  et  al.  were  the  first  to  investigate  system  call  anomalies  for  intrusion  de¬ 
tection  [HFS98],  but  many  have  followed  using  differing  techniques.  Many  of  these 
techniques  were  studied  by  Yasin  [YA04]  and  are  described  here. 
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•  N-Gram  Sequence  of  N  System  Calls 

This  method,  developed  by  Hofmeyr  et  al.  examines  sequences  of  system  calls 
and  compares  them  to  a  profile  of  “normal”  behavior.  The  research  showed  that 
“normal”  profiles  were  distinct  for  different  applications  and  that  it  was  possible 
to  detect  abnormal  behavior  using  the  sequences  [HFS98]. 

•  Finite  State  Automation  Machine  (FSA) 

A  FSA  is  created  under  normal  process  execution  using  the  program  counter 
(PC)  from  which  the  system  call  is  made  as  each  state  and  the  system  call 
name  as  the  transition.  Detection  is  accomplished  by  looking  at  the  PC  from 
which  the  call  is  made  and  determining  if  there  is  a  matching  transition  from 
the  current  state  to  the  new  state  [SBDB01].  One  benefit  of  this  approach  over 
N-Gram  is  that  it  captures  short  and  long-term  correlations  and  the  effects  of 
loops  and  branches. 

An  alternate  approach  to  the  work  of  [SBDB01]  that  claims  to  address  some  of 
their  limitations  is  proposed  by  Yu,  et  al  [YXS+05].  Their  approach  uses  the 
return  address  in  the  function  stack  as  the  state  transition  with  no  meaning 
assigned  to  the  states.  Similar  to  the  FSA  of  Sekar,  et  ah,  if  a  particular 
transition  is  not  present  in  the  FSA  an  intrusion  is  detected.  This  method 
is  immune  to  the  recursive  call  and  dynamically  linked  executable  problems 
encountered  by  the  N-Gram  method. 

•  Static  Analysis 

This  technique  uses  static  analysis  of  system  calls  in  program  source  code  to 
model  “normal”  program  behavior.  Wagner  and  Dean  [WD01]  present  four 
modeling  methods  to  specify  correct  program  behavior.  Their  models  consist  of 
a  trivial  model  that  establishes  a  white  list  of  allowed  system  calls,  a  callgraph 
model  based  on  the  control  flow  of  system  calls,  an  abstract  stack  model  that 
uses  information  from  the  system  call  stack,  and  a  digraph  model  that  is  similar 
to  the  N-gram  approach.  Dynamic  monitoring  is  used  to  determine  if  there  is 
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a  departure  from  normal  program  operation,  as  defined  by  the  model.  Wagner 
and  Dean  claim  the  callgraph  model  does  not  generate  false  alarms.  However, 
the  run-time  overhead  for  their  system  varies  widely  from  less  than  one  second 
to  greater  than  one  hour  [WD01]. 

•  Virtual  Path  Model 

The  Virtual  Path  model  is  based  on  the  interpretation  of  virtual  paths  between 
system  calls.  These  paths  consist  of  the  return  addresses  of  functions  called  in 
between  the  system  calls.  This  model  builds  two  data  structures  during  training; 
the  return  address  table  and  the  virtual  path  table.  The  return  address  table 
contains  entries  for  all  return  addresses  contained  in  the  call  stacks  of  system 
calls.  The  virtual  path  table  contains  all  virtual  paths  that  are  generated  during 
normal  execution.  Detection  is  accomplished  by  extracting  the  current  call  stack 
and  comparing  return  addresses  to  the  return  address  table  and  virtual  paths 
to  the  virtual  path  table.  This  model  is  also  able  to  handle  recursive  calls  and 
dynamically  linked  executables  [FKF+03]. 

2-4-3  Host-Based  IDS  Limitations.  There  are  many  ways  system  call  traces 
are  used  to  detect  intrusions,  but  their  limitations  are  well  documented  [Gar03, 
Chu06].  One  straightforward  method  to  avoid  detection  is  for  an  attacker  to  dis¬ 
cover  an  allowed  sequence  of  system  calls  that  accomplishes  his  or  her  intent  [WS02], 
This  “mimicry  attack”  takes  advantage  of  the  fact  that  many  HIDS  discard  the  pa¬ 
rameters  given  to  each  system  call  and  keep  only  the  system  call  trace.  As  long  as  the 
attacker  does  not  modify  the  sequence  of  system  calls  when  inserting  parameters  the 
attack  will  remain  undetected.  Moreover,  the  permission  level  at  which  the  system  call 
interception  runs  in  many  implementations  is  a  security  issue.  The  system  call  traces 
provided  by  user-level  tools  are  susceptible  to  modification  by  other  processes  or  false 
reporting  from  a  compromised  kernel.  Watson  describes  a  concurrency  vulnerability 
exploit  for  sysjail,  an  application  based  on  the  Systrace  framework  [Wat07].  Fig¬ 
ure  2.12  shows  how  an  attacker  could  take  advantage  of  a  concurrency  vulnerability 
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Figure  2.12:  Race  Exploit  [Wat07] 


and  use  a  race  condition  to  change  the  arguments  passed  to  the  system  call  after  it 
has  already  been  checked  by  the  monitor.  First,  the  original  IP  address  is  set  by  the 
user.  Then,  Systrace  copies  the  address  argument  for  system  call  monitoring.  Next, 
before  the  system  call  executes  the  address  argument  is  replaced  by  another  user 
from  another  processor.  Finally,  the  bind()  system  call  copies  the  altered  argument 
undetected  by  Systrace. 

Many  system-call- monitoring  IDSes  are  “I/O-data-oblivious”,  meaning  they  do 
not  monitor  I/O  operations,  which  results  in  their  vulnerability  to  persistent  inter¬ 
position  attacks  [PSJ08].  Persistent  interposition  attacks  inject  code  using  I/O  oper¬ 
ations  without  altering  the  control-flow  or  other  system  call  arguments.  While  this 
stealth  technique  does  not  result  in  something  as  useful  as  a  root  shell,  it  does  allow 
an  attacker  to  modify  data  on  the  target  without  changing  anything  that  would  be 
detected  by  a  system  call  monitoring  IDS.  Additionally,  if  the  attacker  managed  to 
avoid  detection  while  gaining  access,  the  IDS  could  simply  be  turned  off  since  it  runs 
in  the  compromised  kernel. 
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Finally,  all  of  the  system  call  monitoring  HIDSs  that  have  been  presented  are 
designed  for  Linux.  Unfortunately,  to  port  these  to  Windows  would  be  a  daunting 
task.  Several  issues  make  this  problem  more  difficult  in  Windows  [Chu06]: 

•  System  call  interfaces  are  undocumented  and  inconsistent 

•  Many  Linux  system  call  functions  are  provided  from  within  user  space  in  Win¬ 
dows 

•  Extensive  use  of  dynamically  linked  libraries  makes  creation  of  “normal”  difficult 

•  Intercepting  thread  context  switching  would  be  complex 

2.5  Hardware  Host-Based  Intrusion  Detection  Methods 

Hardware-based  intrusion  detection  and  integrity  monitoring  technologies  have 
been  investigated  to  support  or  replace  software-based  techniques.  These  typically 
involve  the  use  of  specialized  hardware  to  interface  or  monitor  some  portion  of  the 
system.  Using  hardware  makes  the  IDS  much  less  vulnerable  to  any  software-based 
attacks.  However,  the  process  of  interfacing  with  the  data  that  needs  to  be  monitored 
adds  to  the  complexity. 

2.5.1  CuPIDS.  The  Co-Processor-Based  Intrusion  Detection  System  (Cu- 
PIDS)  architecture  is  based  on  parallel  monitoring  of  a  production  process  on  one 
processor  by  a  shadow  process  on  a  separate  processor  [Wil05].  CuPIDS  combines 
both  software  and  hardware  architecture  components  to  achieve  this  monitoring.  Fig¬ 
ure  2.13  shows  an  overview  of  the  CuPIDS  software  architecture.  The  items  on  the 
left  edge  of  the  figure  are  the  CuPIDS  monitors  running  on  the  shadow  processor.  The 
remaining  elements  represent  production  units  running  on  the  production  processor. 
The  overlap  of  the  production  and  shadow  units  demonstrates  the  shadow  monitor’s 
ability  to  monitor  both  passively  and  interactively  the  different  components  of  the 
production  units.  The  CuPIDS  architecture  includes  several  features  that  enable 
its  monitoring  capabilities.  Among  these  are:  secure  inter-CuPIDS  communication, 
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Figure  2.13:  CuPIDS  Architecture  [Wil05] 


the  ability  to  map  virtual  memory  of  a  monitored  process  and  interrupt  and  signal 
interception  [Wil05]. 

The  numerous  parallel  monitoring  capabilities  of  CuPIDS  mean  that  it  is  able  to 
detect  abnormalities  within  the  system  as  they  occur.  Moreover,  security  is  handled 
exclusively  by  the  CuPIDS  shadow  process  allowing  for  more  complicated  detection 
processes  that  might  not  be  possible  on  a  single-processor  system.  One  drawback  of 
CuPIDS  is  the  loss  of  an  entire  CPU  to  security  monitoring.  Quad  core  processors 
are  commonplace  today  and  processors  with  more  cores  are  on  the  horizon.  If  this 
architecture  could  be  adapted  to  multi-core  processors  this  loss  could  become  much 
more  tolerable.  The  communication  between  the  production  and  shadow  process  is 
also  of  some  concern  because  it  relies  on  the  kernel  not  being  compromised.  As 
suggested  by  Williams,  an  architecture  similar  to  CuPIDS  could  be  developed  using 
a  VMM  or  separate  OS  [Wil05]. 
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2.5.2  Co-Pilot.  Integrity  checking  via  a  coprocessor  allows  for  an  efficient 
means  to  verify  host  integrity  while  having  minimal  impact  on  host  performance. 
Copilot,  developed  by  Petroni,  et  al.  [JFMA04],  is  a  coprocessor-based  Linux  kernel 
integrity  monitor  implemented  using  a  PCI  add-in  card.  The  system  detects  kernel 
level  rootkits  comparing  known-good  MD5  hashes  of  important  kernel  data  structures 
with  those  that  it  reads  at  runtime. 

Petroni  et  al.  define  the  following  conditions  that  need  to  be  met  to  successfully 
monitor  host  system  memory: 

•  Unrestricted  access  to  the  full  range  of  host  system’s  main  memory 

•  The  monitor  should  be  non-disruptive  and  invisible  to  the  host  system  to  the 
maximum  degree  possible 

•  The  monitor  should  be  completely  independent  from  the  host  system 

•  The  monitor  should  have  sufficient  processing  power 

•  Provide  the  monitor  with  sufficient  memory  resources 

•  Utilize  out-of-band  reporting  for  secure  communication  with  the  administration 
station 

Many  of  these  requirements  can  be  applied  to  a  VMM-based  IDS.  Despite  meet¬ 
ing  all  of  their  requirements  for  memory  monitoring,  the  Copilot  system  still  has  some 
limitations.  The  system  is  only  a  passive  monitor  and  cannot  interpose  on  the  func¬ 
tions  of  the  host  system.  A  byproduct  of  only  having  access  to  the  host  through  direct 
memory  access  is  that  it  cannot  see  kernel  locks  and  may  read  data  structures  while 
they  are  being  modified.  This  race  condition  could  affect  the  ability  of  the  system 
to  monitor  dynamic  kernel  data  structures.  Moreover,  the  current  implementation 
only  checks  integrity  every  thirty  seconds.  This  is  more  than  enough  time  for  an 
attack  to  cause  damage  to  the  system  before  it  is  detected  [Mot07].  Also,  the  monitor 
is  susceptible  to  relocation  attacks  that  hide  malicious  code  somewhere  other  than 
main  memory,  such  as  the  cache.  Finally,  Rutkowska  outlines  an  attack  technique  us- 
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ing  memory-mapped  I/O  and  the  host  system’s  Northbridge  that  effectively  disables 
PCI-based  host  memory  acquisition  like  Copilot’s  [Rut07a]. 

2.6  Virtual  Machine  Introspection 

The  isolation  provided  by  virtualization  increases  the  security  of  applications 
running  in  different  virtual  machines  and  the  virtual  machine  monitor.  The  low  level 
system  access  of  the  VMM  has  a  side  effect  that  makes  monitoring  and  understanding 
operating  system  level  abstractions  difficult.  This  gap  between  the  VMM  and  the 
internal  operating  system  state,  such  as  process  information  or  disk  structures,  is 
referred  to  as  the  “semantic  gap”  [CN01]. 

Explicit  and  implicit  information  are  two  ways  to  overcome  the  semantic  gap 
between  VMM  and  OS.  Explicit  information  is  obtained  with  the  cooperation  of  the 
guest  OS.  This  requires  modification  of  the  kernel  or  detailed  knowledge  of  the  kernel 
data  structures.  This  information  is  not  always  available  or  its  structure  may  change 
from  version  to  version  [Jon07].  Moreover,  this  information  cannot  be  trusted  because 
a  compromised  guest  OS  could  report  incorrect  or  incomplete  information.  From  the 
perspective  of  security,  implicit  information  is  more  trustworthy  because  it  is  simply 
observed  from  outside  of  the  VM  instead  of  relying  on  the  guest  OS  to  report  it. 
Implicit  information  is  gained  from  analyzing  architectural  events  as  well  as  the  raw 
memory  and  disk  structures  within  the  guest  OS. 

2.6.1  Explicit  Information  Introspection.  Most  methods  used  to  extract 
explicit  information  make  use  of  known  structure  and  location  of  OS  data  structures. 
Information  can  also  be  obtained  from  debugging  symbol  information  such  as  that  in 
the  system. map  hie  in  the  Linux  OS.  Closed-source  operating  systems  and  structure 
differences  from  version  to  version  can  make  it  difficult  to  maintain  programs  that 
obtain  data  with  this  method.  Despite  this  difficulty  many  systems  make  use  of 
explicit  information  because  of  the  accuracy  and  timeliness  it  provides. 


Figure  2.14:  Livewire  Architecture  [GR03] 


2.6. 1.1  Livewire.  Garfinkel  and  Rosenblum  have  developed  Livewire, 
a  VM-based  intrusion  detection  system,  that  uses  kernel  debugging  information  to 
locate  and  read  OS  data  structures  [GR03].  Figure  2.14  illustrates  the  Livewire  ar¬ 
chitecture.  The  architecture  consists  of  a  VMM  interface,  OS  interface  library,  and  a 
policy  engine.  The  VMM  controls  the  interaction  of  these  three  components. 

In  the  case  of  Livewire,  the  OS  interface  library  is  what  bridges  the  semantic 
gap.  The  VMM’s  view  of  memory  is  similar  to  that  given  by  /dev/kmem  from  within 
Linux.  This  allows  Garfinkel  and  Rosenblum  to  use  crash,  a  crash  dump  examination 
tool,  to  read  OS  data  structures  from  within  the  VMM.  Crash  requires  that  the  kernel 
is  compiled  with  debugging  information  enabled  so  the  OS  data  structures  can  be 
resolved  from  raw  memory  [Lin], 

Livewire’s  policy  engine  resides  in  a  virtual  machine  and  relies  on  the  OS  in¬ 
terface  library  and  a  policy  framework  to  communicate  with  the  monitored  VM  and 
the  VMM  respectively.  Actions  of  the  policy  engine  are  based  on  several  polling  and 
event-driven  policy  modules.  These  modules  determine  when  the  policy  engine  will  in¬ 
fluence  execution  of  the  monitored  VM.  The  policy  framework  controls  the  monitored 
VM  via  mechanisms  provided  by  the  VMM  interface. 
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The  VMM  interface  is  composed  of  three  types  of  commands: 


•  Inspection  Commands  -  Allows  the  IDS  to  obtain  VM  state 

•  Monitor  Commands  -  Allow  event  driven  notification 

•  Administrative  Commands  -  Allow  IDS  to  control  monitored  VM 

Garfinkel  and  Rosenblum  acknowledge  several  weaknesses  of  the  Livewire  sys¬ 
tem.  The  weakness  most  relevant  to  this  research  is  their  discussion  of  fooling  or 
compromising  the  OS  interface  library.  The  explicit  information  that  the  OS  inter¬ 
face  library  relies  on  assumes  that  data  structures  in  the  monitored  OS  are  consistent 
with  a  standard  template.  An  attacker  could  modify  the  location  of  important  kernel 
data  structures  so  that  they  are  inconsistent  with  the  IDS  information  and  therefore 
changes  are  undetectable.  Moreover,  a  denial  of  service  attack  on  the  OS  interface 
library  is  possible,  though  Livewire  mitigates  this  problem  by  running  the  library  in 
a  separate  process  and  monitoring  its  execution. 

2. 6. 1.2  VMwatcher.  A  second  VM-based  introspection  architecture 
based  on  guest  view  casting  is  VMwatcher,  developed  by  Jiang  et  al.  [JWX07].  The 
architecture  runs  the  guest  operating  system  on  top  of  a  VMM  running  in  a  host  OS. 
Commercial  malware  detection  utilities  are  run  “out-of-the-box,”  meaning  they  reside 
in  the  host  OS  rather  than  the  guest  OS  being  monitored  [JWX07].  Figure  2.15  shows 
the  VMwatcher  architecture.  Guest  view  casting  is  used  to  overcome  the  semantic 
gap  by  reconstructing  the  guest  OS  memory  structures  and  virtual  disk  structures. 
The  detection  utilities  are  able  to  monitor  the  guest  OS  while  being  isolated  in  the 
host  OS. 

Semantic  view  reconstruction  of  both  guest  memory  and  virtual  disks  is  accom¬ 
plished  using  knowledge  of  their  structure  definitions  and  function  semantics.  File 
system  structure  is  obtained  from  the  virtual  disks  using  the  open  source  Linux  de¬ 
vice  drivers  and  file  system  drivers.  Guest  OS  data  structures  in  memory  are  obtained 
by  combining  addresses  from  the  OS  symbol  information  and  what  is  known  about 
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Figure  2.15:  VMWatcher  Architecture  [JWX07] 


the  translation  from  physical  to  virtual  address  within  the  VM.  The  data  structure 
assumptions  made  by  VMwatcher  make  it  vulnerable  to  the  same  relocation  attacks 
as  Livewire. 

2.6. 1.3  Lares.  The  Lares  architecture  is  based  on  the  Xen  hypervisor 
with  a  specially  designed  virtual  machine  introspection  library  called  XenAccess.  In 
addition  to  a  security  monitoring  VM,  the  Lares  architecture  adds  hooks  into  the  guest 
operating  system  to  allow  for  active  monitoring  for  malware  or  intrusions  [PCSL08]. 
The  guest  OS  is  instrumented  with  jumps  in  strategic  locations,  such  as  program 
code,  jump  tables  or  other  important  structures.  Figure  2.16  shows  the  Lares  archi¬ 
tecture.  These  hooks  redirect  execution  to  an  embedded  trampoline  in  the  guest  OS. 
This  trampoline  securely  transfers  information  to  the  security  monitoring  VM  via  the 
hypervisor.  Upon  receiving  information  from  the  trampoline,  the  security  VM  uses 
an  introspection  API  to  obtain  additional  information  about  the  state  of  the  guest 
OS  based  on  the  needs  of  the  security  application.  The  hooks  and  trampoline  are 
protected  from  malicious  code  in  the  guest  OS  by  a  memory  protection  component 
in  the  hypervisor.  This  component  marks  the  memory  location  of  hooks  as  read  only 
causing  a  trap  to  the  hypervisor  if  an  access  is  attempted. 

2.6.2  Implicit  Information  Introspection.  Implicit  information  is  gleaned 
from  what  is  known  about  the  system  architecture.  Interactions  with  specific  struc¬ 
tures  in  the  architecture,  such  as  registers,  I/O  subsystem  or  the  memory  management 
unit  (MMU).  This  information  does  not  depend  on  the  OS  and  would  be  difficult  for 
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Figure  2.16:  Lares  Architecture  [PCSL08] 

a  compromised  OS  to  spoof.  However,  it  is  not  without  its  limitations.  Due  to 
the  methods  used  to  obtain  implicit  information  it  is  not  likely  that  a  VMM  could 
produce  all  useful  OS  structures  this  way.  Moreover,  Jones  demonstrated  that  im¬ 
plicit  information  sometimes  suffers  from  delays  and  in  some  cases  produces  incorrect 
information  [Jon07]. 

2. 6.2. 1  Antfarm  and  Lycosid.  One  source  of  implicit  information  is  the 
x86  virtual  memory  architecture.  A  virtual  address  is  translated  to  a  physical  address 
using  page  directories  and  page  tables  stored  in  memory.  The  system  configuration 
register  CR3  holds  the  physical  address  of  the  active  address  space’s  page  directory. 
Additionally,  the  most  recently  used  page-directory  and  page  table  entries  are  stored 
in  the  translation  lookaside  buffers  (TLB).  Figure  2.17  shows  how  x86  virtual  address 
translation  occurs.  The  page  directory  address  from  the  page  directory  base  register, 
CR3,  is  used  to  locate  the  page  directory.  The  most  significant  10  bits  of  the  linear 
address  are  used  to  index  the  page  directory  and  locate  a  pointer  to  the  appropriate 
page  table.  Linear  address  bits  21  through  12  are  used  to  index  the  page  table  for  the 
page  table  entry,  which  when  combined  with  the  12  least  significant  bits  of  the  linear 
address  index  the  physical  page. 

CR3  is  a  privileged  register  and  will  cause  an  exit  to  the  VMM  if  written  to.  Ant¬ 
farm  takes  advantage  of  this  to  track  processes  in  the  guest  virtual  machine  [Jon07].  It 
defines  a  unique  address  space  identifier  (ASID)  that  corresponds  to  a  unique  process. 
When  a  new  page  directory  physical  address  is  written  to  CR3  it  is  recorded  in  the 
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Figure  2.17:  x86  Virtual  Address  Translation  [Cor08a] 

ASID  registry  as  that  process’  ASID.  Antfarm  needs  to  observe  three  process- related 
events;  process  creation,  context  switch,  and  process  exit. 

•  Process  Creation  and  Context  Switch 

When  the  VMM  detects  that  CR3  has  been  written  to,  the  value  is  compared  to 
those  in  the  ASID  registry.  If  the  value  is  not  present,  then  a  new  address  space 
has  been  created  and  the  ASID  is  added  to  the  ASID  registry.  If  it  is  already 
present,  then  a  context  switch  has  occurred  and  the  new  ASID  is  active. 

•  Process  Exit 

In  order  to  isolate  the  different  address  spaces,  the  operating  system  must  ensure 
that  page  directories  and  page  tables  are  not  reused  without  first  being  cleared  of 
their  values.  Clearing  of  non-privileged  page  table  entries  is  done  on  process  exit 
by  Windows  and  Linux.  Tracking  when  the  number  of  non-privileged  page  table 
entries  reaches  zero  gives  the  VMM  the  first  indication  that  a  process  has  exited. 
Additionally,  the  TLB  must  be  purged  when  an  address  space  is  deallocated. 
In  the  x86  architecture,  this  happens  automatically  when  the  value  in  CR3  is 
changed.  Therefore,  the  VMM  can  infer  that  a  process  with  the  outgoing  ASID 
has  exited  when  there  are  zero  non-privileged  page  table  entries  and  the  value 
in  CR3  is  changed  [Jon07]. 
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Jones  uses  Antfarm  to  implement  the  cross-view  validation  hidden  process  de¬ 
tector,  Lycosid  [Jon07].  The  VMM-based  detector  uses  Antfarm  to  obtain  a  trusted 
view  of  the  system  processes.  Next,  an  untrusted  view  is  obtained  via  a  network 
connection  to  the  VM  and  a  user-level  utility  such  as  ps  for  Linux  or  tasklist.exe 
for  Windows.  These  two  different  views  are  linked  together  by  matching  CPU  time 
of  each  process.  Finally,  statistical  techniques  are  used  to  increase  the  accuracy  of 
detection  in  the  face  of  interference  and  synchronization.  Lycosid  is  vulnerable  to 
desynchronization  attacks,  but  this  can  be  overcome  by  ensuring  that  any  user-land 
process  monitor  was  using  the  same  view  as  Lycosid  [Jon07]. 

2. 7  Summary 

This  chapter  presents  fundamental  concepts  related  to  virtualization,  host-based 
intrusion  detection,  and  operating  systems  and  recent  research  in  those  areas.  First, 
virtualization  methods  are  presented.  Next,  important  Windows  operating  system 
data  structures  are  explored  in  detail.  Then,  malware  is  defined  and  discussed.  Later, 
principles  of  host-based  intrusion  detection  are  detailed.  Finally,  virtual  machine 
introspection  is  explained. 
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III.  Methodology 

This  chapter  discusses  the  methodology  used  to  measure  the  performance  of  the  op¬ 
erating  system  and  rootkit  detection  functions  applied  to  Windows  virtual  machines. 
Section  3.1  defines  the  problem.  Section  3.2  introduces  the  research  goals.  Section  3.3 
presents  the  research  approach.  Section  3.4  discusses  the  experimental  design  for  op¬ 
erating  system  detection  and  SSDT  location  and  hook  detection. 

3.1  Problem  Definition 

The  development  of  virtualization  technology  has  provided  a  new  method  for 
isolated  OS  monitoring.  Security  monitoring  can  be  performed  from  the  VMM  or  a 
trusted  VM  using  virtual  machine  introspection.  Hardware  virtualization  extensions 
isolate  the  security  monitor  from  the  guest  OS  being  monitored.  However,  the  se¬ 
mantic  gap  must  be  bridged  to  accomplish  this  monitoring.  Livewire,  VMWatcher, 
Lares,  and  Antfarm  utilize  virtual  machine  introspection  to  monitor  guest  operat¬ 
ing  systems  [GR03,  JWX07,  PCSL08,  JADAD08].  Systems  using  explicit  information 
(Livewire,  VMWatcher,  and  Lares)  require  precompiled  OS  information  for  the  guest 
operating  system.  Moreover,  implicit  information  is  limited  and  has  only  been  used  by 
Antfarm  to  monitor  processes  running  in  a  guest  OS.  This  research  attempts  to  find 
a  middle  ground  between  explicit  and  implicit  information  introspection.  Guest  OS 
information  is  automatically  obtained  from  guest  memory  or  trusted  sources  and  used 
in  conjunction  with  the  XenAccess  library  to  monitor  the  guest’s  SSDT  for  hooks. 

3.2  Goals 

The  methodology  defined  in  this  chapter  is  used  to  enable  detection  of  SSDT 
hooks  in  a  Windows  guest  domain  from  Xen’s  domain  0.  Each  of  the  goals  defined 
below  provide  the  means  to  carry  out  this  detection: 

•  Detect  the  Guest  Operating  System 

•  Identify  Version-Specific  Offsets 
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•  Locate  OS  Data  Structures  to  Be  Monitored 


It  is  hypothesized  that  the  Windows  operating  system  version  can  be  detected 
from  domain  0  by  examining  the  guest  memory  using  forensic  techniques.  This  version 
information  can  be  used  to  retrieve  the  required  offset  information.  Additionally,  it 
is  hypothesized  that  using  techniques  employed  by  malware  writers  [C01] ,  the  system 
service  dispatch  table  can  be  located  and  monitored  for  hooks. 

3.3  Approach 

The  hardware  used  for  this  research  is  a  Dell  D630  laptop  with  an  Intel  Core 
2  Duo  T7300  processor,  two  gigabytes  of  memory,  and  a  120  gigabyte  hard  drive. 
The  T7300  processor  is  Intel  Virtualization  Technology  capable  and  enables  the  use 
of  hardware-assisted  virtualization  on  the  test  platform. 

The  XenAccess  library,  version  0.4,  is  used  to  enable  the  virtual  machine  in¬ 
trospection  necessary  to  monitor  the  Windows  guest  operating  systems.  The  library 
provides  the  ability  to  view  memory  pages  of  one  domain  from  another  privileged 
domain  [PCL07,  Pay07].  It  gives  a  raw  view  of  guest  memory  that  is  much  like  that 
of  a  forensic  memory  dump.  Therefore,  many  tools  and  techniques  developed  for 
forensic  analysis  can  be  applied  to  dynamically  monitor  guest  operating  systems  from 
the  management  domain.  This  library  is  used  because  the  availability  of  source  code 
enables  modification  to  suit  the  needs  of  this  research.  Introspection  is  accomplished 
by  using  a  configuration  hie  based  on  prior  knowledge  of  the  guest  OS  data  struc¬ 
tures.  This  research  eliminates  the  need  for  a  configuration  hie  by  using  OS  detection 
results  and  information  obtained  from  guest  memory  to  configure  the  XenAccess  li¬ 
brary.  Compatibility  with  XenAccess  drives  the  choice  of  many  other  portions  of  the 
testing  environment  and  the  core  components  are  similar  to  [PCSL08].  The  newest 
version  of  Xen  that  works  with  XenAccess  0.4  and  Windows  hardware-assisted  virtual 
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Table  3.1:  XenAccess  Required  Data  Structure  Information 


XenAccess  name 

Windows  Data  Structure 

win_tasks 

EPROCESS->ActiveProcessLinks 

win_pdbase 

EPROCESS->Pcb->DirectoryTableBase 

win_pid 

EPROCESS->UniqueProcessId 

win_peb 

EPR0CESS->Peb 

win_iba 

EPROCESS->Peb->ImageBaseAddress 

win_ph 

EPROCESS->Peb->ProcessHeap 

machines  is  Xen  version  3.I.4.1  Additionally,  Fedora  8  is  used  for  the  Xen  domain  0, 
as  it  is  the  newest  version  of  Fedora  that  runs  as  a  Xen  domain  0. 

The  Windows  hardware-assisted  virtual  machines  are  created  and  configured  as 
described  in  the  example  provided  with  the  Xen  source  code,  xmexample .  hvm.  A  ten- 
gigabyte  virtual  disk  is  created  for  each  guest  domain,  and  the  OS  is  installed  from 
base  version  CD  media  and  upgraded  to  each  service  pack  version.  Each  guest  OS  is 
allotted  512  megabytes  of  memory  and  one  virtual  CPU.  The  setup  and  configuration 
of  the  test  environment  is  described  in  detail  in  Appendix  C. 

3.4  Experimental  Design 

3-4-1  Operating  System  Detection.  In  order  to  realize  the  goal  of  version- 
independent,  automatic  Windows  guest  OS  introspection,  it  is  necessary  to  imple¬ 
ment  an  OS  detection  function  as  part  of  this  research.  XenAccess  requires  knowl¬ 
edge  of  the  location  of  several  operating  system  data  structures  in  order  to  be  fully 
functional.  For  example,  until  the  version-specific  EPROCESS->ActiveProcessLinks, 
EPROCESS->Pcb->DirectoryTableBase,  and  EPROCESS->UniqueProcessId  offsets  are 
known,  only  the  kernel  memory  can  be  mapped  to  dornO.  Table  3.1  shows  the  data 
structures  required  by  XenAccess  for  Windows  guest  domains.  These  offsets  can 
change  for  different  versions  of  Windows  as  well  as  with  Windows  service  pack  up¬ 
dates  or  hotfixes.  This  is  the  impetus  for  detecting  the  version  of  Windows  that 
is  running  in  a  guest  domain.  The  offset  information  for  each  version  of  Windows 

1XenAccess  0.5,  released  on  January  5,  2009  claims  support  for  Xen  3.3.0 
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can  be  obtained  by  looking  at  the  EPROCESS  structure  in  the  Windows  kernel  de¬ 
bugger  (windbg)  using  the  dt  -v  -b  _EPR0CESS  command.  Appendix  B  shows  the 
output  of  the  dt  command  for  Windows  XP  Service  Pack  2  with  the  pertinent  en¬ 
tries  in  boldface  type2.  In  addition  to  offsets,  XenAccess  requires  a  hie  containing 
the  kernel  exports  for  the  particular  version  of  windows.  This  hie  can  be  obtained  by 
using  the  the  dumpbin .  exe  utility  provided  with  Microsoft  Visual  Studio  by  executing 
dumpbin.exe  /exports  ntoskrnl.exe.  Alternatively,  dumpbin. exe  comes  with  the 
free  MASM32  development  environment.  XenAccess  requires  the  export  information  to 
be  contained  in  a  text  hie  pointed  to  by  the  configuration  hie.  XenAccess  uses  this  hie 
to  lookup  symbols  from  disk  whenever  the  windows_symbol_to_address ()  function 
is  called. 

Determining  the  OS  version  begins  with  a  list  of  known  base  addresses  where  the 
Windows  kernel  is  loaded  into  memory.  Like  the  offsets  described  above,  this  address 
can  change  between  major  versions  of  Windows  as  well  as  service  packs  and  hotfixes. 
This  information  is  also  obtained  from  the  kernel  debugger.  The  technique  used  for  OS 
detection  is  based  on  a  Perl  script  used  to  analyze  memory  dumps  by  Harlan  Carvey 
called  kern.pl  [Car07]  [Car06].  It  was  chosen  because  export  symbol  information 
contained  in  the  kernel  executable  can  be  obtained  with  minimal  effort  after  the 
OS  detection  is  complete.  This  completely  automates  the  XenAccess  configuration 
process  by  using  the  exports  retrieved  from  memory  and  the  known  offsets  for  the 
detected  version.  For  an  added  measure  of  security,  the  exports  obtained  from  memory 
can  be  compared  to  a  known  set  of  export  symbols  obtained  from  an  untainted  kernel 
executable. 

The  OS  detection  algorithm  works  by  starting  at  a  known  kernel  base  address 
and  stepping  through  memory  guided  by  the  PECOFF  and  VS  VERSION  INFO 
formats  as  shown  in  Figure  3.1  [Cor08d]  [Cor08e].  Arrows  from  one  box  to  another 
indicate  following  a  pointer,  while  the  lines  terminated  by  a  dot  indicate  an  offset  into 

2Output  of  the  dt  command  for  all  OS  versions  used  in  this  research  are  included  in  electronic 
form  with  the  source  code. 
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Figure  3.1:  OS  Detection  Process 


the  same  region  of  memory.  If  the  Oxf  eef  04bd  signature  in  the  VS  VERSION  JNFO 
structure  is  found,  a  successful  detection  is  reported,  the  kernel  base  address  is  set, 
and  the  version  information  strings  are  saved.  If  any  signatures  are  not  found  or  an 
attempt  to  map  a  specific  memory  page  results  in  a  null  pointer,  testing  moves  to  the 
next  base  address. 

After  OS  detection  is  finished,  many  pointers  to  the  kernel  executable  still  exist. 
This  feature  allows  for  the  retrieval  of  the  addresses  of  functions  exported  by  the 
kernel.  The  kernel’s  optional  header,  where  the  address  to  the  resource  table  is  found, 
also  contains  the  address  of  the  kernel’s  export  table.  The  kernel  export  area  contains 
three  parallel  tables  with  the  export  names,  addresses,  and  ordinals.  In  order  to 


39 


put  them  in  the  name  and  address  pair  format  desired  by  XenAccess,  they  must  be 
reindexed  using  the  pseudocode  shown  in  Listing  III.  1. 

Listing  III.  1 : 

i  =  Sear ch_ExportNamePoint erTable ( ExportName ) ; 
ordinal  =  ExportOrdinalTable  [i]  ; 

SymbolRVA  =  Export AddressTable  [ordinal  -  OrdinalBas e ]  ; 

With  this  step  complete,  the  exports  obtained  from  the  kernel  image  in  memory  are 
stored  in  the  XenAccess  instance  structure  for  later  retrieval  using 
windows_symbol_to_address_from_mem() ,  which  replaces  the  standard  library  func¬ 
tion,  windows_symbol_to_address () . 

34.1.1  Performance  Tests.  The  operating  system  detection  algorithm 
is  evaluated  using  three  experiments  scripted  from  the  Xen  domain  0.  First,  the 
accuracy  of  the  operating  system  function  is  tested.  Next,  the  initialization  time  is 
compared  to  the  standard  library.  Last,  the  performance  of  the  new  symbol  lookup 
function  is  compared  to  the  standard  library  function. 

Operating  System.  Detection  Performance.  The  experiment  con¬ 
sists  of  thirty  trials  for  each  of  nine  Windows  versions  and  Ubuntu  8.10.  Tabic  3.2 
lists  the  OS  versions  tested  and  the  kernel  base  address  associated  with  that  version. 
For  the  purposes  of  the  XenAccess  library,  Windows  versions  with  the  same  base 
address  and  data  structure  format  can  be  processed  identically.  However,  they  can 
be  distinguished  using  the  contents  of  the  VS_VERS10N_INF0  structure  if  further 
granularity  is  desired.  OS  detection  is  considered  a  success  if  the  correct  kernel  base 
address  is  returned.  The  script  that  tests  each  OS  is  shown  in  Listing  111.2,  with 
<WindowsVersion>  representing  the  names  of  the  OSes  in  Table  3.2.  The  body  of 
the  loop  consists  of  starting  the  VM,  sleeping  for  60  seconds  while  it  boots3,  running 
the  os-detect  program  with  output  directed  to  a  hie,  and  destroying  the  VM.  This 
process  is  repeated  30  times. 

360  seconds  was  chosen  to  accommodate  the  OS  with  the  longest  boot  time,  Windows  Vista. 


40 


Table  3.2:  Operating  System  Base  Addresses 


Version 

Base  Address 

Windows  2000  Professional  SP4 

0x80400000 

Windows  XP  Professional 

0x804d0000 

Windows  XP  Professional  SP1 

0x804d4000 

Windows  XP  Professional  SPla 

0x804d4000 

Windows  XP  Professional  SP2 

0x804d7000 

Windows  XP  Professional  SP3 

0x804d7000 

Windows  2003  Server 

0x804de000 

Windows  2003  Server  SP1 

0x80800000 

Windows  Vista  Business 

0x81800000 

Ubuntu  Intrepid  Ibex  8.10 

OxcOOOOOOO 

Listing  III. 2: 

for  ((  i  =  1;  i  <=  30;  i++) ) 
do 

xm  create  / etc/xen/<WindowsVersion > . hvm 
sleep  60 

./os-detect  <WindowsVersion >HVM  >  re suit s / OSdet e ct /< Windows Vers i on > -\ $i 
xm  destroy  <WindowsVer sion >HVM 

done 


XenAccess  Initialization  Time  Performance.  During  initializa¬ 
tion,  the  standard  XenAccess  library  must  read  in  the  operating  system  information 
from  the  configuration  hie  and  scan  for  the  kernel  image  in  memory.  In  contrast,  the 
modified  version  used  for  this  research  scans  known  kernel  base  addresses  and  then 
sets  configuration  information  based  on  the  OS  detected.  The  initialization  process 
used  in  this  research  eliminates  any  disk  accesses  and  blind  memory  scanning  and 
therefore  is  more  efficient.  For  the  modified  library,  initialization  time  also  includes 
the  time  to  process  the  kernel  exports  because  they  are  read  during  initialization. 

In  order  to  test  the  performance  of  the  standard  XenAccess  library  initialization 
versus  the  modified  version,  the  test  program  is  instrumented  to  read  the  processor’s 
time  stamp  counter  before  the  library  initialization  function  is  called  and  immediately 
after.  This  is  done  using  the  RDTSC  instruction,  which  on  the  Intel  Core  2  Duo  proces- 
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sor,  provides  a  monotonically  increasing  unique  value,  or  tick,  that  is  used  to  calculate 
relative  performance  [Cor08b].  The  code  in  Listing  III. 3  shows  the  time_hack()  func¬ 
tion  that  is  used  make  call  to  RDTSC.  The  volatile  keyword  is  used  to  ensure  that  the 
code  runs  when  specified  and  is  not  relocated  by  the  compiler  during  its  optimiza¬ 
tions.  The  initialization  performance  test  consists  of  1,000  trials  using  each  library 
on  each  of  the  nine  Windows  versions  in  Table  3.2,  for  a  total  of  18,000  trials. 

Listing  III. 3: 

uint64_t  t ime_hack ( ) 

{ 

uint32_t  lo  ,  hi ; 

_  _  asm_  _  __volatile__  ("rdtsc"  :  "  =  a"  (lo),  "=d"  (hi)); 

return  (uint64_t)hi  <<  32  I  lo ; 

> 


Symbol  Lookup  Performance.  The  time_hack()  function  is  also 
used  to  test  the  performance  of  the  new  windows_symbol_to_address_from_mem() 
function  versus  the  standard  library  function  windows_symbol_to_address () .  The 
respective  initialization  procedures  for  the  standard  library  and  the  modified  library 
are  carried  out  before  the  first  call  to  tirae_hack().  Since  both  libraries  search  the 
symbols  linearly  and  the  number  of  symbols  varies  with  different  versions,  the  first, 
middle,  and  last  symbols  were  chosen  as  search  queries.  Each  trial  consisting  of 
the  three  separately  measured  lookups  was  performed  1,000  times  for  each  library. 
Therefore,  a  total  of  6,000  lookups  are  performed  for  each  of  9  operating  system 
versions  for  a  total  of  54,000  measured  symbol  lookups. 

3.4.2  SSDT  Location  and  Hook  Detection.  As  defined  by  Hofmeyr  et  ah, 
a  host-based  intrusion  detection  system  must  perform  three  functions:  data  collec¬ 
tion,  data  classification,  and  data  reporting  [HFS98].  The  system  developed  for  this 
research  accomplishes  data  collection  via  the  XenAccess  library  with  modifications, 
data  classification  by  checking  kernel  memory  boundaries,  and  data  reporting  by  iden¬ 
tifying  hooks  and  removing  them  if  desired. 
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3-4-2. 1  Data  Collection  with  XenAccess.  The  first  step  in  enabling 
XenAccess  to  perform  data  collection  for  the  purposes  of  intrusion  detection  is  to 
detect  the  OS  version  that  is  running.  Once  this  is  accomplished,  as  discussed  in 
Section  3.4.1,  the  library  is  initialized  and  introspection  is  performed  from  the  Xen 
domain  0.  This  provides  a  raw  view  of  memory,  akin  to  a  memory  dump.  The 
locations  of  OS  data  structures  need  to  be  determined  so  that  they  can  be  monitored. 
The  SSDT  is  chosen  for  this  experiment  because  approximately  fifty  percent  of  rootkits 
in  the  wild  use  this  technique  [KS07,  Rie06]. 

The  address  of  the  SSDT  can  be  obtained  using  the  kernel  export, 
KeServiceDescriptorTable  as  described  in  [DPB99].  However,  as  discussed  in  Sec¬ 
tion  2.2.2,  this  does  not  contain  information  for  services  exported  from  Win32k.sys. 
This  research  determines  the  location  of  the  SSDT  and  shadow  SSDT  by  using  a 
technique  similar  to  COldcrow  [C01] .  The  information  necessary  to  locate  the  SSDT 
is  contained  as  part  of  the  ETHREAD  structure  of  a  Windows  GDI  process.  Figure  3.2 
illustrates  the  steps  taken  to  find  the  SSDT  using  bold  arrows.  First,  the  kernel 
export  PsInitialSystemProcess  is  used  to  gain  entry  into  the  doubly  linked  Win¬ 
dows  process  list.  This  provides  a  pointer  to  the  System  process,  which  is  not  a 
Windows  GDI  process.  In  Windows  GDI  processes,  the  Win32Process  field  in  the 
EPROCESS  structure  will  be  non-null.  Next,  the  list  is  traversed  until  the  current 
EPR0CESS->Win32Process  field  is  not  null.  To  get  to  the  ETHREAD  structure  the 
pointer  in  the  EPROCESS->Pcb->ThreadListHead  field  is  followed  to  the  ETHREAD 
structure.  Finally,  the  ETHREAD  structure  contains  the  DirectoryTable  field  which 
points  to  the  Shadow  SSDT. 

3. 4-2. 2  Data  Classification.  In  order  to  classify  a  particular  address 
in  the  SSDT  as  safe  or  malicious,  the  location  and  size  of  the  kernel  and  win32k.sys 
in  memory  are  needed.  All  addresses  in  the  SSDT  should  point  to  an  address  in 
the  kernel’s  memory  space,  and  addresses  in  the  shadow  SSDT  should  point  into  the 
memory  space  of  Win32k.sys.  This  information  can  be  obtained  from  the  kernel 
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Figure  3.2:  Shadow  SSDT  Location 


module  entry  for  each  hie  in  the  Windows  driver  list  as  described  by  Hoglund  [HB05]. 
This  technique  is  adapted  for  use  from  outside  the  guest  OS  using  XenAccess. 

First  a  pointer  to  the  module  list  must  be  obtained.  The  necessary  kernel 
variable,  PsLoadedModuleList  is  not  exported  by  the  kernel.  For  Windows  XP  and 
20034,  it  can  be  found  in  a  structure  pointed  to  by  the  KdVersionBlock  held  of 
the  processor  control  region  structure,  KPCR  [Bar, Ion].  In  kernel  mode,  the  KPCR  is 
always  located  at  OxffdffOOO.  At  offset  0x34,  the  KdVersionBlock  held  points  to  the 
_DBGKD_GET_VERSION64  structure.  This  structure  is  used  by  the  kernel  debugger 
and  contains  the  kernel  base  address,  the  PsLoadedModuleList  address,  and  a  pointer 
to  the  KDDEBUGGER  DATA64  structure  which  contains  many  more  unexported 
kernel  variables.  The  format  of  these  structures  is  listed  in  Appendix  B. 

Using  PsLoadedModuleList  the  module  list  is  traversed  enumerating  each  mod¬ 
ule’s  memory  space  using  the  base  address  and  size  found  in  the  module  structure. 
If  any  address  in  the  SSDT  does  not  point  to  a  location  within  the  kernel’s  memory 

4For  Windows  2000  and  Windows  Vista  PsLoadedModuleList  is  hardcoded  in  the  library 
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space,  it  is  classified  as  a  hook  and  the  module  list  is  checked  to  see  if  it  points  to 
another  module. 

3. 4 .2. 3  Data  Reporting.  The  hook  detector  reports  the  system  call 
number  of  any  hook  and  the  module  that  it  points  to,  if  applicable.  The  hook  could 
point  to  a  hidden  module  not  in  the  module  list  or  to  a  location  that  is  not  in  any 
module’s  memory  space.  The  system  call  number  can  be  used  to  determine  what 
function  is  being  hooked  using  a  system  call  table  [Pro09].  This  gives  an  indication 
about  what  the  hook  might  be  trying  to  achieve. 

This  research  implements  the  SSDT  monitor  as  a  polling  process  from  the  Xen 
domain  0.  The  polling  frequency  is  as  fast  as  the  processor  will  allow,  approximately 
utilizing  an  entire  core  of  the  dual-core  processor.  For  each  iteration  of  the  polling 
loop,  the  SSDT  is  located  and  checked  for  hooks.  Hooks  are  automatically  replaced 
with  a  known  good  value  obtained  before  infection.  The  hooked  system  call  number, 
target  address,  and  kernel  module’s  address  space  the  target  falls  in  are  recorded  in 
the  result  hie. 

3. 4 -2. 4  Hook  Detection  Performance.  To  test  the  ability  of  the  hook 
detector  to  locate  hooks  in  the  SSDT,  two  malware  programs  from  the  wild  are  used. 
Both  the  Agony  rootkit  and  ProAgent  spy  tool  are  known  to  install  hooks  into  the 
SSDT  and  they  can  be  made  to  persist  between  restarts  of  the  operating  system. 
The  malware  is  installed  on  VMs  for  each  of  the  nine  Windows  versions.  Shown  in 
Listing  III. 4,  the  same  script  used  to  run  the  OS  detection  experiment  is  modified  to 
run  the  check-ssdt  program  30  times  for  each  version  of  Windows. 
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Table  3.3:  Agony  Rootkit  Options  and  Hooked  System  Calls 


Option 

System  Call  Hooked 

-p  <process  name> 

NtQuerySystemlnf ormation 

-f  <hle/directory  name> 

NtQueryDirectoryFile 

-k  <registry  key> 

NtEnumerateKey 

-v  <registry  value> 

NtEnumerateValueKey 

-tcp  <port> 

NtDeviceloControlFile 

-udp  <port> 

NtDeviceloControlFile 

-space 

<drivc  letter>:<space  to  hide> 

NtQueryDirectoryFile 
NtQueryVoluraelnf ormationFile 

Listing  III. 4: 

for  ((  i  =  1;  i  <=  30;  i++) ) 
do 

xm  create  / etc/xen/ <WindowsVersion > . hvm 
sleep  60 

./check-ssdt  <WindowsVer s ion >HVM  >  re suit s / <malware >/< Windows Vers ion > -\ $i 
xm  destroy  <WindowsVer sion >HVM 

done 


Agony  Rootkit.  Agony  is  an  open  source,  kernel-mode  rootkit 
that  hides  processes,  hies,  directories,  registry  keys  and  values,  TCP  and  UDP  ports, 
Windows  services,  and  falsifies  disk  space.  It  is  obtained  from  [Int06]  and  compiled 
from  source  using  Dev-C++.  Source  code  analysis  reveals  that  Agony  uses  SSDT 
hooks  to  accomplish  all  hiding  functions  except  service  hiding.  Agony  is  a  command 
line  tool  with  options  allowing  the  user  to  specify  what  to  hide.  Table  3.3  lists  the 
hiding  options  with  the  appropriate  system  call  that  is  hooked  by  that  option.  For 
this  experiment  the  following  command  line  is  used: 
agony  -r  -p  notepad.exe  -f  agony. c  -k  test  -v  test  \ 

-tcp  135  -udp  135  -space  c:10 

This  results  in  the  hooking  of  all  six  system  calls  listed  in  Table  3.3  and  persists  upon 
restart  due  to  the  -r  option. 
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ProAgent.  The  ProAgent  spy  tool  is  a  rootkit  that  collects  pass¬ 
word  and  user  information  on  the  infected  system  and  emails  it  to  the  attacker.  The 
program  installs  a  driver  named  JiurlPortHide .  sys  onto  the  system.  This  driver  is 
used  to  hide  the  port  that  the  rootkit  uses  to  send  the  collected  information.  Source 
code  for  JiurlPortHide .  sys  obtained  from  [Jiu08],  reveals  that  this  driver  hooks 
the  NtDeviceloControlFile  system  call  and  persists  through  system  restarts  using 
system  registry  entries. 

3. 5  Summary 

This  chapter  explains  the  methodology  used  to  evaluate  the  operating  system 
detection  algorithm  and  SSDT  hook  detector  implemented  in  this  research.  The 
operating  system  detection  algorithm  is  evaluated  based  on  detection  accuracy,  ini¬ 
tialization  time,  and  kernel  export  symbol  lookup  time.  The  SSDT  hook  detector  is 
evaluated  based  on  the  ability  to  detect  hooks  placed  in  the  SSDT  by  two  rootkits. 
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IV.  Results  and  Analysis 

This  chapter  presents  and  analyzes  the  experimental  results.  Section  4.1.1  analyzes 
the  results  of  the  operating  system  detection  and  symbol  lookup  experiments.  Next, 
Section  4.1.2  presents  the  results  of  the  rootkit  hook  detection  work.  Finally,  Sec¬ 
tion  4.4  summarizes  the  overall  results  from  this  research. 

4-1  Results  and  Analysis  of  Experiments 

4-1.1  Operating  System-  Detection  Analysis.  The  operating  system  detection 
experiment  tests  if  the  correct  kernel  base  address  is  detected  for  each  Windows 
version.  Table  4.1  shows  the  outcome  of  the  30  trials  for  each  operating  system.  The 
results  show  a  positive  detection  for  all  versions  of  Windows. 

Since  no  Linux  OS  detection  is  implemented,  the  Ubuntu  Linux  VM  resulted  in 
zero  detections,  as  expected. 

The  Ubuntu  Linux  VM  resulted  in  zero  detections,  as  expected.  False  positive 
and  false  negative  errors  can  be  caused  by  malicious  alteration  of  kernel  memory. 
False  negatives  are  easier  to  cause  because  only  one  piece  of  data  along  the  detection 
algorithm’s  path  in  Figure  3.1  on  page  39  needs  to  be  changed  to  cause  a  negative 
result.  Creating  a  false  positive  would  require  detailed  knowledge  of  the  detection 
algorithm  and  precisely  crafted  changes  in  kernel  memory.  Additionally,  these  changes 
may  result  in  an  unstable  kernel. 

4. 1.1.1  Initialization  Time.  The  standard  XenAccess  library  must 
access  the  disk  to  read  in  the  configuration  hie  and  scan  memory  to  find  the  base  of 
the  kernel  image.  This  results  in  a  longer  initialization  time  and  additional  effort  to 
manually  build  a  configuration  hie  and  kernel  export  hie.  A  1-sample  t-test  with  a  95 
percent  confidence  interval  is  applied  to  data  obtained  from  the  time_hack()  function 
in  the  detection  algorithm.  The  results  of  the  t-tests  for  each  Windows  version  are 
contained  in  Table  4.2.  The  table  contains  a  row  entry  for  the  standard  and  modified 
libraries  with  each  Windows  version.  The  two  entries  for  each  Windows  version,  for  the 
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Table  4.1:  Operating  System  Detection  Results 


Version 

Base  Address 

Successful  Detections 

Windows  2000  Professional  SP4 

0x80400000 

30/30 

Windows  XP  Professional 

0x804d0000 

30/30 

Windows  XP  Professional  SP1 

0x804d4000 

30/30 

Windows  XP  Professional  SPla 

0x804d4000 

30/30 

Windows  XP  Professional  SP2 

0x804d7000 

30/30 

Windows  XP  Professional  SP3 

0x804d7000 

30/30 

Windows  2003  Server 

0x804de000 

30/30 

Windows  2003  Server  SP1 

0x80800000 

30/30 

Windows  Vista  Business 

0x81800000 

30/30 

Ubuntu  Intrepid  Ibex  8.10 

OxcOOOOOOO 

0/30 

modified  library  and  standard  library,  are  grouped  using  double  lines  for  comparison. 
Each  entry  in  the  table  shows  the  mean,  standard  deviation,  standard  error,  and  a 
95%  confidence  interval  for  that  Windows  version.  Figure  4.1  uses  data  from  the 
t-test  to  compare  the  mean  initialization  time  of  the  standard  XenAccess  library 
versus  the  modified  version  of  the  library  for  each  operating  system  investigated.  The 
confidence  intervals  for  many  of  the  versions  are  too  small  to  be  seen  and  show  up 
as  a  dash.  The  columns  greater  than  109  CPU  ticks  represent  versions  of  Windows 
for  which  the  standard  XenAccess  library’s  initial  scanning  method  fails  to  find  the 
kernel  base  address.  At  this  failure  point,  execution  time  is  already  approximately 
100  times  greater  than  the  modified  library,  so  the  trial  is  terminated.  Therefore, 
actual  initialization  times  are  on  the  order  of  4  *  1012  ticks,  or  about  40  minutes. 

The  failure  of  the  initial  scanning  method  may  be  a  bug  in  XenAccess,  in  which 
case  it  is  expected  that  the  standard  library  initialization  times  would  be  similar 
for  all  Windows  versions.  Including  the  trials  that  are  terminated  early,  the  overall 
mean  speedup  is  approximately  105.  Including  only  those  operating  systems  for  which 
the  standard  XenAccess  library’s  initial  scanning  method  succeeds,  the  overall  mean 
speedup  is  1.9. 
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Figure  4.1:  Mean  Initialization  Times  -  95%  Confidence  Interval 


Table  4.2:  1-sample  t-Test  for  Initialization  Time  Comparison 


Version 

N 

Mean 

StDev 

SE  Mean 

95%  Cl 

Windows  2000  SP4  Mod 

1000 

18803414 

2262363 

71542 

(  18663024,  18943805) 

Windows  2000  SP4  Std 

1000 

22517533 

4517216 

142847 

(  22237219,  22797847) 

Windows  XP  Mod 

1000 

21996755 

6042263 

191073 

(  21621804,  22371706) 

Windows  XP  Std 

1000 

4145416238 

350270867 

11076537 

(4123680290,  4167152187) 

Windows  XP  SP1  Mod 

1000 

22083674 

5108116 

161533 

(  21766691,  22400656) 

Windows  XP  SP1  Std 

1000 

4504633660 

251540793 

7954418 

(4489024375,  4520242945) 

Windows  XP  SPla  Mod 

1000 

21775002 

3572091 

112959 

(  21553337,  21996667) 

Windows  XP  SPla  Std 

1000 

4290522026 

249610260 

7893369 

(4275032540,  4306011512) 

Windows  XP  SP2  Mod 

1000 

21933356 

2883767 

91193 

(  21754404,  22112307) 

Windows  XP  SP2  Std 

1000 

27226046 

5697695 

180177 

(  26872478,  27579615) 

Windows  XP  SP3  Mod 

1000 

22152455 

2954825 

93440 

(  21969094,  22335815) 

Windows  XP  SP3  Std 

1000 

27111457 

5686774 

179832 

(  26758566,  27464348) 

Windows  2003  Mod 

1000 

23005312 

5609042 

177373 

(  22657245,  23353379) 

Windows  2003  Std 

1000 

4143102517 

271308223 

8579519 

(4126266570,  4159938463) 

Windows  2003  SP1  Mod 

1000 

24293921 

10416096 

329386 

(  23647553,  24940288) 

Windows  2003  SP1  Std 

1000 

4057345810 

139567138 

4413500 

(4048685016,  4066006605) 

Windows  Vista  Mod 

1000 

32786362 

17041459 

538898 

(  31728859,  33843864) 

Windows  Vista  Std 

1000 

128445627 

20999008 

664047 

(  127142540,  129748714) 

4- 1.1. 2  Symbol  Lookup  Time.  The  symbol  lookup  time  is  compared 
based  on  calls  to  the  windows_symbol_to_address ()  function  for  the  standard 
XenAccess  library  and  calls  to  windows_symbol_to_address_from_mem()  for  the 
modified  version.  A  1-sample  t-test  with  a  95  percent  confidence  interval  is  con¬ 
ducted  for  the  data  obtained  from  the  symbol  lookup  time  trials.  The  tabular  data  is 
contained  in  Appendix  A.  The  means  and  confidence  intervals  are  used  to  construct 
Figure  4.2  which  shows  the  average  number  of  CPU  ticks  taken  to  look  up  a  symbol 
on  each  operating  system  with  the  standard  and  modified  XenAccess  libraries.  In¬ 
dividual  plots  for  each  operating  system  and  symbol  lookup  that  include  confidence 
intervals  are  found  in  Appendix  A.  On  average,  the  library  modified  for  this  research 
is  one  order  of  magnitude  faster  than  the  standard  library  for  all  operating  systems 
tested. 

XenAccess  maintains  a  25-entry  least  recently  used  (LRU)  cache  for  symbols. 
This  means  that  after  the  initial  lookup,  subsequent  lookups  of  the  same  symbol  will 
not  need  to  access  the  disk  as  long  as  it  has  not  been  evicted.  Without  a  representative 
workload,  it  is  difficult  to  calculate  the  miss  rate  of  this  cache.  Because  both  versions 
of  XenAccess  benefit  from  this  cache,  the  difference  in  lookup  speed  shown  above  is 
only  valid  for  initial  lookups. 

In  addition  to  an  improvement  in  performance  and  eliminating  the  need  for  a 
file  containing  kernel  exports,  parsing  the  kernel  exports  from  guest  memory  offers 
another  avenue  for  intrusion  detection.  Crossview  verification  can  be  implemented 
by  comparing  the  symbols  from  guest  memory  with  symbols  from  a  trusted  source, 
such  as  an  isolated  Windows  installation  from  trusted  media  or  the  Microsoft  symbol 
server.  The  Microsoft  symbol  server  provides  debugging  information  for  Windows 
operating  system  files.  Any  differences  in  the  symbol  information  obtained  from  the 
untrusted  and  trusted  sources  indicate  that  the  kernel  has  been  tampered  with. 
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Figure  4.2:  Average  CPU  Ticks  for  Kernel  Symbol  Lookup 

4-1-2  SSDT  Location  and  Hook  Detection  Analysis.  Tables  4.3  and  4.4 
show  the  results  of  the  SSDT  hook  detection  experiments.  Each  of  the  30  trials 
produce  identical  results.  The  SSDT  entry  number  reported  by  the  detector  is  cross- 
referenced  using  the  Metasploit  Project  system  call  table  [Pro09]  to  obtain  the  name 
of  the  hooked  system  call.  Note  that  the  system  call  numbers  only  change  with  major 
versions  of  Windows  so  they  are  grouped  together.  The  owning  kernel  module  where 
the  hook  points  to  is  reported  by  the  detector  and  also  listed  in  the  tables. 

The  detector  correctly  reports  the  hooks  installed  by  both  rootkits.  For  Agony, 
the  same  six  system  calls  are  hooked  in  each  version  of  Windows.  This  is  the  reason 
that  only  the  system  call  numbers  change  in  Table  4.3.  ProAgent  demonstrates  the 
same  behavior  with  all  versions  hooking  NtDeviceloControlFile. 
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Table  4.3:  Hooks  Detected  for  Agony  Rootkit 


Version 

Entry  # 

System  Call  Name 

Owning  Module 

Windows  2000  SP4 

0x38 

NtDeviceloControlFile 

agony . sys 

0x3c 

NtEnumerateKey 

agony . sys 

0x3d 

NtEnumerateValueKey 

agony . sys 

0x7d 

NtQueryDirectoryFile 

agony . sys 

0x97 

NtQuerySystemlnf ormation 

agony . sys 

0x9d 

NtQueryVolumelnf ormationFile 

agony . sys 

Windows  XP, 

0x42 

NtDeviceloControlFile 

agony . sys 

Windows  XP  SP1, 

0x47 

NtEnumerateKey 

agony . sys 

Windows  XP  SPla, 

0x49 

NtEnumerateValueKey 

agony . sys 

Windows  XP  SP2, 

0x91 

NtQueryDirectoryFile 

agony . sys 

Windows  XP  SP3 

Oxad 

NtQuerySystemlnf ormation 

agony . sys 

0xb3 

NtQueryVolumelnf ormationFile 

agony . sys 

Windows  2003, 

0x45 

NtDeviceloControlFile 

agony . sys 

Windows  2003  SP1 

0x4b 

NtEnumerateKey 

agony . sys 

0x4d 

NtEnumerateValueKey 

agony . sys 

0x97 

NtQueryDirectoryFile 

agony . sys 

0xb5 

NtQuerySystemlnf ormation 

agony . sys 

Oxbb 

NtQueryVolumelnf ormationFile 

agony . sys 

Windows  Vista  Business 

0x7f 

NtDeviceloControlFile 

agony . sys 

0x85 

NtEnumerateKey 

agony . sys 

0x88 

NtEnumerateValueKey 

agony . sys 

Oxda 

NtQueryDirectoryFile 

agony . sys 

Oxf  8 

NtQuerySystemlnf ormation 

agony . sys 

Oxf  e 

NtQueryVolumelnf ormationFile 

agony . sys 

Table  4.4:  Hooks  Detected  for  ProAgent  Rootkit 


Version 

Entry  7^ 

System  Call  Name 

Owning  Module 

Windows  2000  SP4 

0x38 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  XP 

0x42 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  XP  SP1 

0x42 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  XP  SPla 

0x42 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  XP  SP2 

0x42 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  XP  SP3 

0x42 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  2003 

0x45 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  2003  SP1 

0x45 

NtDeviceloControlFile 

JiurlPortHide . sys 

Windows  Vista  Business 

0x7f 

NtDeviceloControlFile 

JiurlPortHide . sys 

4-2  Overall  Analysis 

This  research  successfully  implements  an  operating  system  detection  function 
to  initialize  the  XenAccess  library  with  appropriate  configuration  information.  Addi¬ 
tionally,  export  symbol  information  is  obtained  from  memory  eliminating  the  need  for 
a  symbol  hie  and  increasing  initial  symbol  lookup  speed  by  approximately  10  times. 
Moreover,  initialization  with  the  modified  library  achieves  a  speedup  of  1.9  over  the 
standard  library. 

The  hook  detection  software  successfully  retrieves  the  location  of  SSDT  from 
guest  memory  and  uses  it  to  monitor  for  hooks.  The  hook  detector  removes  hooks 
placed  in  the  SSDT  automatically  and  replaces  them  with  values  obtained  before 
hooking.  The  Agony  and  ProAgent  rootkits  are  used  to  install  hooks  in  the  SSDT 
and  are  successfully  detected  by  the  monitor. 


4-3  Limitations 

The  hook  detector  implemented  in  this  research  is  a  proof  of  concept  for  auto¬ 
mated  location  of  the  SSDT  from  the  Xen  management  domain.  Many  other  OS  data 
structures  can  be  targeted  by  malware.  Additionally,  the  SSDT  is  hooked  by  many 
personal  security  products.  These  hooks  will  be  reported  just  as  with  the  rootkit 
hooks  creating  false  positives.  One  solution  to  this  problem  is  to  create  a  whitelist  of 
kernel  modules  that  are  allowed  to  install  hooks. 
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4-4  Summary 

This  chapter  analyzes  the  experimental  results  obtained  from  the  operating 
system  detection  and  hook  detection  experiments.  The  initialization  time  and  symbol 
look  time  are  compared  for  the  standard  and  modified  XenAccess  library.  Next, 
the  ability  of  the  hook  detector  to  detect  hooks  placed  in  the  SSDT  by  malware  is 
evaluated.  Finally,  an  overall  analysis  of  the  results  is  presented. 
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V.  Conclusions 


This  chapter  provides  a  summary  of  key  findings  of  this  research.  Section  5.1  draws 
conclusions  based  on  experimental  results.  Section  5.2  discusses  the  impact  of  this 
research.  Section  5.3  gives  recommendations  for  future  research  in  this  area. 

5.1  Research  Conclusions 

The  XenAccess  library  can  be  automatically  configured  and  used  to  monitor  the 
system  service  dispatch  table  of  a  Windows  VM  from  the  Xen  management  domain. 
Obstacles  caused  by  the  semantic  gap  are  overcome  by  investigating  guest  OS  kernel 
memory  using  XenAccess  and  applying  forensic  memory  processing  techniques  as 
listed  below. 

•  Detecting  the  Guest  Operating  System 

A  Windows  operating  system  version  detection  algorithm  used  for  analysis  of 
memory  dumps  [Car06]  is  adapted  for  use  with  XenAccess  and  successfully 
detects  nine  recent  versions  of  Windows  from  the  Xen  management  domain. 
A  speedup  of  1.9,  on  average,  is  observed  for  XenAccess  initialization  and  an 
initialization  file  is  not  required. 

•  Identifying  Version- Specific  Offsets 

The  Windows  kernel  exports  are  obtained  during  initialization  of  the  modified 
library.  This  eliminates  the  need  for  a  system  map  file.  Version-specific  offsets 
in  the  EPROCESS  structure  must  still  be  obtained  using  the  kernel  debugger. 
However,  they  are  integrated  into  the  library  code  and  automatically  set  for  the 
appropriate  version  as  part  of  the  operating  system  detection  function. 

•  Locating  OS  Data  Structures  to  Be  Monitored 

The  system  service  dispatch  table  is  located  by  adapting  a  technique  used  by 
malware  [C01],  to  parse  it  from  the  guest  OS  memory.  Hooks  are  detected  using 
the  kernel  memory  space  as  a  boundary  and  the  kernel  module  list  to  discover 
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where  they  point.  Hooks  implanted  in  the  SSDT  by  the  Agony  and  ProAgent 
rootkits  are  detected  on  all  nine  Windows  versions  tested. 

5.2  Research  Impact 

This  research  demonstrates  the  value  of  using  forensic  techniques  with  virtual 
machine  introspection  to  conduct  host-based  intrusion  detection.  Moreover,  it  is  the 
first  to  integrate  operating  system  detection  as  a  means  to  automate  introspection 
library  configuration  and  is  a  step  toward  OS  independent  virtual  machine  introspec¬ 
tion.  This  technique  combined  with  hardware-assisted  virtualization  is  a  step  forward 
from  current  ring  0  intrusion  detection  software. 

The  XenAccess  library  provides  a  promising  open-source  virtual  machine  intro¬ 
spection  platform.  The  OS  detection  and  data  structure  monitoring  implemented  in 
this  thesis  extend  the  capabilities  of  XenAccess.  Additionally,  the  library  initialization 
is  1.9  times  faster  and  initial  symbol  lookups  are  an  order  of  magnitude  faster.  More¬ 
over,  XenAccess  0.5  includes  the  scanning  of  known  operating  system  base  addresses 
during  initialization  to  speed  the  process  [Pag08].  Ideas  presented  as  future  work  will 
also  enhance  the  XenAccess  library  and  increase  security  for  virtual  machines  running 
in  Xen. 

5.3  Recommendations  for  Future  Work 

5.3.1  Version  Specific  Operating  System  Offsets.  Modifications  made  to  the 
XenAccess  library  for  operating  system  detection  used  in  this  research  still  require 
prior  knowledge  of  OS  data  structures.  It  may  be  possible  for  future  research  to 
eliminate  this  need  for  prior  knowledge  by  obtaining  kernel  data  structure  informa¬ 
tion  directly  from  the  Microsoft  symbol  server  when  needed.  Signature  information 
needed  to  retrieve  kernel  symbol  information  is  contained  within  the  kernel  memory. 
Additionally,  the  _KDDEBUGGEFLDATA64  structure  defined  in  Appendix  B  con¬ 
tains  the  EPR0CESS->Peb  and  EPROCESS->Pcb->DirectoryTableBase  offsets  needed 
by  XenAccess. 


5.3.2  OS  Data  Structure  Monitoring.  This  research  implements  a  monitor 
for  the  SSDT.  This  functionality  can  be  extended  to  other  important  operating  system 
data  structures.  The  shadow  SSDT  can  be  monitored  for  Windows  GDI  function 
hooks.  Monitors  for  the  interrupt  descriptor  table  and  driver  IRP  tables  can  also  be 
implemented.  Extending  this  research  to  detect  in-line  system  call  function  hooks 
only  requires  checking  the  first  5  bytes  of  the  function  at  every  address  in  the  SSDT 
for  jump  instruction  opcodes.  A  similar  approach  can  be  used  for  in-line  function 
hook  elsewhere. 

5.3.3  System  Call  Interposition.  The  Lares  architecture,  discussed  in  Sec¬ 
tion  2. 6. 1.3  could  be  used  as  a  data  collection  mechanism  for  system  call  traces. 
Software  host-based  intrusion  detection  systems  principles  like  those  discussed  in  Sec¬ 
tion  2.4  could  then  be  applied  for  intrusion  detection  with  these  traces. 

5.3.4  Linux  OS  Detection.  The  OS  detection  algorithm  used  in  this  research 
is  Windows  specific.  However,  a  Linux  OS  detection  function  would  also  ease  the 
burden  of  library  configuration.  Implementing  a  reliable  Linux  OS  detector  may  not 
be  feasible  clue  to  the  large  number  of  different  versions  and  the  ability  to  create 
custom  kernels. 

5.4  Summary 

This  chapter  presents  the  research  conclusions.  Research  impact  is  discussed, 
and  recommendations  for  future  work  are  given. 
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Appendix  A.  Symbol  Lookup  Data 
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Tabic  A.l:  1-Sample  t-Test  of  Symbol  Lookup  Times  -  Standard  Library 


Variable 

N 

Mean 

StDev 

SE  Mean 

95%  Cl 

Windows  2000  SP4  First  Symbol 

1000 

102883 

9471 

300 

(  102295,  103471) 

Windows  2000  SP4  Middle  Symbol 

1000 

786362 

1943459 

61458 

(  665761,  906962) 

Windows  2000  SP4  Last  Symbol 

1000 

1350774 

575127 

18187 

(1315085,  1386463) 

Windows  XP  First  Symbol 

1000 

105914 

16877 

534 

(  104867,  106962) 

Windows  XP  Middle  Symbol 

1000 

929719 

2744273 

86782 

(  759424,  1100014) 

Windows  XP  Last  Symbol 

1000 

1516830 

655517 

20729 

(1476152,  1557508) 

Windows  XP  SP1  First  Symbol 

1000 

106086 

20574 

651 

(  104810,  107363) 

Windows  XP  SP1  Middle  Symbol 

1000 

774600 

345322 

10920 

(  753171,  796029) 

Windows  XP  SP1  Last  Symbol 

1000 

1577734 

846350 

26764 

(1525214,  1630254) 

Windows  XP  SPla  First  Symbol 

1000 

125571 

339413 

10733 

(  104508,  146633) 

Windows  XP  SPla  Middle  Symbol 

1000 

781595 

432523 

13678 

(  754754,  808435) 

Windows  XP  SPla  Last  Symbol 

1000 

1525383 

667492 

21108 

(1483962,  1566804) 

Windows  XP  SP2  First  Symbol 

1000 

119357 

278664 

8812 

(  102064,  136649) 

Windows  XP  SP2  Middle  Symbol 

1000 

806261 

487225 

15407 

(  776026,  836496) 

Windows  XP  SP2  Last  Symbol 

1000 

1571303 

765028 

24192 

(1523829,  1618776) 

Windows  XP  SP3  First  Symbol 

1000 

106128 

10943 

346 

(  105449,  106807) 

Windows  XP  SP3  Middle  Symbol 

1000 

780530 

282694 

8940 

(  762987,  798072) 

Windows  XP  SP3  Last  Symbol 

1000 

1532426 

618272 

19551 

(1494060,  1570793) 

Windows  2003  First  Symbol 

1000 

133269 

405252 

12815 

(  108121,  158416) 

Windows  2003  Middle  Symbol 

1000 

817704 

439093 

13885 

(  790456,  844952) 

Windows  2003  Last  Symbol 

1000 

1546842 

490806 

15521 

(1516385,  1577299) 

Windows  2003  SP1  First  Symbol 

1000 

106804 

15441 

488 

(  105846,  107762) 

Windows  2003  SP1  Middle  Symbol 

1000 

831238 

338085 

10691 

(  810258,  852217) 

Windows  2003  SP1  Last  Symbol 

1000 

1639586 

615861 

19475 

(1601369,  1677803) 

Windows  Vista  First  Symbol 

1000 

112401 

178000 

5629 

(  101355,  123447) 

Windows  Vista  Middle  Symbol 

1000 

1114950 

533549 

16872 

(1081841,  1148060) 

Windows  Vista  Last  Symbol 

1000 

2115550 

627884 

19855 

(2076587,  2154514) 

Table  A. 2:  1-Sample  t-Test  of  Symbol  Lookup  Times  -  Modified  Library 


Variable 

N 

Mean 

StDev 

SE  Mean 

95%  Cl 

Windows  2000  SP4  First  Symbol 

1000 

61734 

8088 

256 

(  61232,  62236) 

Windows  2000  SP4  Middle  Symbol 

1000 

75085 

198847 

6288 

(  62746,  87425) 

Windows  2000  SP4  Last  Symbol 

1000 

85485 

12416 

393 

(  84715,  86256) 

Windows  XP  First  Symbol 

1000 

54777 

5986 

189 

(  54406,  55149) 

Windows  XP  Middle  Symbol 

1000 

73366 

17210 

544 

(  72298,  74434) 

Windows  XP  Last  Symbol 

1000 

95312 

44161 

1397 

(  92571,  98052) 

Windows  XP  SP1  First  Symbol 

1000 

54226 

12423 

393 

(  53455,  54997) 

Windows  XP  SP1  Middle  Symbol 

1000 

78425 

190746 

6032 

(  66589,  90262) 

Windows  XP  SP1  Last  Symbol 

1000 

91308 

4687 

148 

(  91018,  91599) 

Windows  XP  SPla  First  Symbol 

1000 

53801 

7905 

250 

(  53310,  54291) 

Windows  XP  SPla  Middle  Symbol 

1000 

72410 

3947 

125 

(  72165,  72655) 

Windows  XP  SPla  Last  Symbol 

1000 

94274 

65038 

2057 

(  90238,  98310) 

Windows  XP  SP2  First  Symbol 

1000 

62021 

199532 

6310 

(  49639,  74403) 

Windows  XP  SP2  Middle  Symbol 

1000 

72840 

4064 

129 

(  72588,  73092) 

Windows  XP  SP2  Last  Symbol 

1000 

92291 

8977 

284 

(  91733,  92848) 

Windows  XP  SP3  First  Symbol 

1000 

54212 

8854 

280 

(  53663,  54762) 

Windows  XP  SP3  Middle  Symbol 

1000 

72616 

4995 

158 

(  72306,  72926) 

Windows  XP  SP3  Last  Symbol 

1000 

97976 

196954 

6228 

(  85754, 110198) 

Windows  2003  First  Symbol 

1000 

60731 

199680 

6314 

(  48340,  73123) 

Windows  2003  Middle  Symbol 

1000 

86005 

273248 

8641 

(  69049,  102961) 

Windows  2003  Last  Symbol 

1000 

106328 

275337 

8707 

(  89242,  123414) 

Windows  2003  SP1  First  Symbol 

1000 

63349 

280264 

8863 

(  45957,  80740) 

Windows  2003  SP1  Middle  Symbol 

1000 

83159 

216395 

6843 

(  69730,  96587) 

Windows  2003  SP1  Last  Symbol 

1000 

104531 

202544 

6405 

(  91963,  117100) 

Windows  Vista  First  Symbol 

1000 

56257 

38061 

1204 

(  53895,  58618) 

Windows  Vista  Middle  Symbol 

1000 

89037 

224591 

7102 

(  75100,  102974) 

Windows  Vista  Last  Symbol 

1000 

120575 

307522 

9725 

(101492,  139658) 

CPU  Ticks 


1600000 


05 

GO 


1400000 


1200000 


1000000 


800000 


600000 


400000 


200000 


0 


2000  SP4  2000  SP4  2000  SP4 

First  Symbol  Middle  Symbol  Last  Symbol 

Windows  Version  /  Symbol  Location 


■  Modified 
Standard 


Figure  A.l:  Symbol  Lookup  Comparison  for  Windows  2000  SP4 
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A. 2:  Symbol  Lookup  Comparison  for  Windows  XP 
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Figure  A. 3:  Symbol  Lookup  Comparison  for  Windows  XP  SP1 
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Figure  A. 4:  Symbol  Lookup  Comparison  for  Windows  XP  SPla 
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Figure  A. 5:  Symbol  Lookup  Comparison  for  Windows  XP  SP2 
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Figure  A. 6:  Symbol  Lookup  Comparison  for  Windows  XP  SP3 
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Figure  A. 7:  Symbol  Lookup  Comparison  for  Windows  2003 
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Figure  A. 9:  Symbol  Lookup  Comparison  for  Windows  Vista  Business 
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Appendix  B.  Windows  Operating  System  Data  Structures 

B.l  EPROCESS  Structure  for  Windows  XP  SP2 

Listing  B.l:  Appendix2/xpsp2.txt 


kd>  dt  -v  -b  .EPROCESS 
ntdll ! .EPROCESS 

struct  .EPROCESS ,  107  elements  ,  0x260  bytes 


+0x000  Pcb 

+0x000  Header  : 

+0x000  Type 
+0x001  Absolute 
+0x002  Size 
+0x003  Inserted 
+0x004  SignalState 
+0x008  WaitListHead 
+0x000  Flink 
+0x004  Blink 
+0x010  Prof ileListHead 
+0x000  Flink 
+0x004  Blink 

+oxoi8  DirectoryTableBase 


struct  .KPR0CESS ,  29  elements ,  0x6c  bytes 
:  struct  .DISPATCHER.HEADER ,  6  elements ,  0x10  bytes 
UChar 
UChar 
UChar 
UChar 
Int  4B 

struct  .LIST.ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 

struct  .LIST.ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 

:  (2  elements)  Uint4B 


+0x020  LdtDescriptor 
+0x000  LimitLow 
+0x002  BaseLow 
+0x004  HighWord 
+0x000  Bytes 

+0x000  BaseMid 
+0x001  Flagsl 
+0x002  Flags2 
+0x003  BaseHi 
+0x000  Bits 

+0x000  BaseMid 
+0x000  Type 
+0x000  Dpi 
+0x000  Pres 
+0x000  LimitHi 
+0x000  Sys 
+0x000  Reserved.O 
+0x000  Default.Big 
+0x000  Granularity 
+0x000  BaseHi 
+0x028  Int21Descriptor 
+0x000  Offset 
+0x002  Selector 
+0x004  Access 
+0x006  ExtendedOf f set 
+0x030  IopmOffset 
+0x032  Iopl 
+0x033  Unused 
+0x034  Act iveProcessors 
+0x038  KernelTime 
+0x03c  UserTime 
+0x040  ReadyListHead 
+0x000  Flink 
+0x004  Blink 
+0x048  SwapListEntry 
+0x000  Next 

+0x04c  VdmTrapcHandler 


struct  .KGDTENTRY ,  3  elements ,  0x8  bytes 
Uint 2B 
Uint 2B 

union  ..unnamed  ,  2  elements ,  0x4  bytes 
:  struct  ..unnamed ,  4  elements ,  0x4  bytes 
UChar 
UChar 
UChar 
UChar 

truct  ..unnamed ,  10  elements  ,  0x4  bytes 
Bitfield  Pos  0,  8  Bits 
Bitfield  Pos  8,  5  Bits 
Bitfield  Pos  13,  2  Bits 

Bitfield  Pos  15,  1  Bit 

Bitfield  Pos  16,  4  Bits 

Bitfield  Pos  20,  1  Bit 

Bitfield  Pos  21,  1  Bit 

Bitfield  Pos  22,  1  Bit 

Bitfield  Pos  23,  1  Bit 

Bitfield  Pos  24,  8  Bits 

struct  .KIDTENTRY  ,  4  elements  ,  0x8  bytes 
Uint 2B 
Uint 2B 
Uint 2B 
Uint 2B 
Uint 2B 
UChar 
UChar 
Uint4B 
Uint4B 
Uint 4B 

struct  .LIST.ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 

struct  .SINGLE.LIST.ENTRY  ,  1  elements  ,  0x4  bytes 
:  Ptr32  to 
Ptr32  to 


72 


58 

63 

68 

73 

78 

83 

88 

93 

98 

103 

108 

113 


+0x050  ThreadListHead 
+0x000  Flink 
+0x004  Blink 


:  struct  _LIST_ENTRY ,  2  elements ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 


+0x058 

ProcessLock 

:  Uint4B 

+0x05c 

Af  f inity 

:  Uint4B 

+0x060 

St ackCount 

:  Uint 2B 

+0x062 

BasePr ior ity 

:  Char 

+0x063 

Thread Quantum 

:  Char 

+0x064 

AutoAlignment 

:  UChar 

+0x065 

State 

:  UChar 

+0x066 

ThreadSeed 

:  UChar 

+0x067 

DisableBoost 

:  UChar 

+0x068 

PowerStat e 

:  UChar 

+0x069 

Di sable Quantum 

:  UChar 

+0x06a 

IdealNode 

:  UChar 

+0x06b 

Flags 

:  struct 

+0x000  ExecuteDisable 
+0x000  ExecuteEnable 


struct  _KEXECUTE_ OPT IONS  ,  7  elements  ,  Oxl 
Bitfield  Pos  0,  1  Bit 
Bitfield  Pos  1,  1  Bit 
+0x000  DisableThunkEmulation  :  Bitfield  Pos  2,  1  Bit 
+0x000  Permanent  :  Bitfield  Pos  3,  1  Bit 

+0x000  Execut eDispat chEnable  :  Bitfield  Pos  4,  1  Bit 
+0x000  ImageDispat chEnable  :  Bitfield  Pos  5,  1  Bit 


+0x000  Spare 
+0x06b  ExecuteOpt ions 
+0x06c  ProcessLock  : 

+0x000  Waiting 
+0x000  Exclusive 
+0x000  Shared 
+0x000  Value 
+0x000  Ptr 

+0x070  CreateTime  : 

+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0x078  ExitTime 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0x080  RundownProt ect  : 
+0x000  Count 
+0x000  Ptr 

+0x084  IMqueRrocessId  : 
+0x088  ActiveRrocessLinks 

+0x000  Flink 
+0x004  Blink 
+0x090  QuotaUsage 
+0x09c  QuotaPeak 
+0x0a8  CommitCharge 
+0x0ac  PeakVirtualSize 
+0x0b0  VirtualSize 
+0x0b4  SessionProcessLinks 
+0x000  Flink 
+0x004  Blink 
+0x0bc  DebugPort 


:  Bitfield  Pos  6,  2  Bits 
:  UChar 

struct  _EX_PUSH_L0CK ,  5  elements ,  0x4  bytes 
Bitfield  Pos  0,  1  Bit 
Bitfield  Pos  1,  1  Bit 
Bitfield  Pos  2,  30  Bits 
Uint4B 
Ptr32  to 

union  _LARGE_INTEGER  ,  4  elements  ,  0x8  bytes 
Uint4B 
Int4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int4B 
:  Int8B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int  4B 

struct  ..unnamed  ,  2  elements  ,  0x8  bytes 
:  Uint4B 
:  Int4B 
:  Int8B 

struct  _EX_RUND0WN_REF  ,  2  elements  ,  0x4  bytes 
:  Uint4B 
:  Ptr32  to 
Ptr32  to 

:  struct  _LIST_ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 

(3  elements)  Uint4B 
(3  elements)  Uint4B 
Uint 4B 
Uint 4B 
Uint 4B 

truct  _LIST_ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 
Ptr32  to 


73 


bytes 


118 

123 

128 

133 

138 

143 

148 

153 

158 

163 

168 

173 


Uint4B 


+OxOcO  Except ionPort 
+0x0c4  ObjectTable 
+0x0c8  Token 

+0x000  Object 
+0x000  RefCnt 
+0x000  Value 
+0 xOcc  WorkingSetLock 
+0x000  Count 
+0x004  Owner 
+0x008  Contention 
+0x00c  Event 

+0x000  Header 
+0x000  Type 
+0x001  Absolute 
+0x002  Size 
+0x003  Inserted 
+0x004  SignalState 
+0x008  WaitListHead 
+0x000  Flink 
+0x004  Blink 

+0x01c  Oldlrql  : 

+0x0ec  WorkingSetPage  :  Uint4B 
+0x0f0  AddressCreat ionLock  : 

+0x000  Count  : 

+0x004  Owner  : 

+0x008  Contention  : 

+0x00c  Event  : 

+0x000  Header 
+0x000  Type 
+0x001  Absolute 
+0x002  Size 
+0x003  Inserted 
+0x004  SignalState 
+0x008  WaitListHead 
+0x000  Flink 
+0x004  Blink 
+0x01c  Oldlrql 
+0x110  HyperSpaceLock 
+0x114  ForklnProgress 
+0x118  Hardwar eTrigger 
+0xllc  VadRoot 
+0x120  VadHint 
+0x124  CloneRoot 
+0x128  NumberOf Privat ePages  :  Uint4B 
+0xl2c  NumberOf LockedPages  :  Uint4B 

+01130  Win32Rrocess  :  ptr32  to 

+0x134  Job 

+0x138  Sect ionOb j ect 
+0xl3c  Sect ionBaseAddress 
+0x140  QuotaBlock 
+0x144  WorkingSetWat ch  : 

+0x148  Win32WindowStat ion 
+0xl4c  InheritedFromUniqueProcessId 
+0x150  Ldtlnf ormation 
+0x154  VadFreeHint 
+0x158  VdmObjects 
+0xl5c  DeviceMap 
+0x160  PhysicalVadList 
+0x000  Flink 
+0x004  Blink 


Ptr32  to 
Ptr32  to 

struct  _EX_FAST_REF ,  3  elements ,  0x4  bytes 
Ptr32  to 

Bitfield  Pos  0,  3  Bits 
Uint4B 

struct  _FAST_MUTEX  ,  5  elements  ,  0x20  bytes 
Int4B 
Ptr32  to 
Uint4B 

struct  _KEVENT ,  1  elements  ,  0x10  bytes 
:  struct  _DISPATCHER_HEADER ,  6  elements ,  0x10  bytes 
UChar 
UChar 
UChar 
UChar 
Int4B 

struct  _LIST_ENTRY ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 


Ptr32  to 


_FAST_MUTEX  ,  5  elements  ,  0x20  bytes 


struct 
Int4B 
Ptr32  to 
Uint 4B 

struct  _KEVENT  ,  1  elements  ,  0x10  bytes 
:  struct  _DISPATCHER_HEADER ,  6  elements ,  0x10  bytes 
UChar 
UChar 
UChar 
UChar 
Int4B 

struct  _LIST_ENTRY ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 


:  Uint4B 
Uint4B 
Ptr32  to 
Uint 4B 
Ptr32  to 
Ptr32  to 
Ptr32  to 


Ptr32  to 
Ptr32  to 
:  Ptr32  to 
Ptr32  to 
Ptr32  to 
:  Ptr32  to 


Ptr32  to 

Ptr32  to 
Ptr32  to 
Ptr32  to 
Ptr32  to 

struct  _LIST_ENTRY  ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 


74 


178 

183 

188 

193 

198 

203 

208 

213 

218 

223 

228 

233 


+0x168  PageDirect oryPt e  :  struct  _HARDWARE_PTE_X86 ,  13  elements ,  0x4  bytes 


+0x000 

Valid 

Bitf ield 

Pos 

o. 

1 

Bit 

+0x000 

Write 

Bitf ield 

Pos 

1 , 

1 

Bit 

+0x000 

Owner 

Bitf ield 

Pos 

2, 

1 

Bit 

+0x000 

Writ eThrough 

Bitf ield 

Pos 

3, 

1 

Bit 

+0x000 

CacheDisable 

Bitf ield 

Pos 

4, 

1 

Bit 

+0x000 

Accessed 

Bitf ield 

Pos 

5  , 

1 

Bit 

+0x000 

Dirty 

Bitf ield 

Pos 

6  , 

1 

Bit 

+0x000 

LargePage 

Bitfield 

Pos 

7, 

1 

Bit 

+0x000 

Global 

Bitf ield 

Pos 

8, 

1 

Bit 

+0x000 

CopyOnWrit e 

Bitf ield 

Pos 

9, 

1 

Bit 

+0x000 

Prototype 

Bitf ield 

Pos 

10 

1  Bi 

+0x000 

reserved 

Bitf ield 

Pos 

11 

1  Bi 

+0x000 

Page Frame Number 

Bitf ield 

Pos 

12 

20  B 

168  Filler  : 

Uint 8B 

170  Session  : 

Ptr32  to 

174  Im 

ageFileName  : 

(16 

elements 

) 

UChar 

+0x184  JobLinks 
+0x000  Flink 
+0x004  Blink 
+0xl8c  LockedPagesList 
+0x190  ThreadListHead 
+0x000  Flink 
+0x004  Blink 
+0x198  SecurityPort 
+0xl9c  PaeTop 
+0xla0  Act iveThreads 
+0xla4  GrantedAccess 
+0xla8  Def aultHardErrorProcessing  : 
+0xlac  Las tThreadExit St atus  :  Int4B 


struct  _LIST_ENTRY ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 
Ptr32  to 

struct  _LIST_ENTRY ,  2  elements  ,  0x8  bytes 
:  Ptr32  to 
:  Ptr32  to 
Ptr32  to 
Ptr32  to 
Uint 4B 
Uint4B 


+o  xibo  Peb 

+0xlb4  Pref et chTrace  : 

+0x000  Object 
+0x000  RefCnt 
+0x000  Value 

+0xlb8  ReadOperat ionCount 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xlc0  Writ eOperat ionCount 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xlc8  OtherOperat ionCount 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xld0  ReadTransf erCount  : 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 


Ptr32  to 

struct  _EX_FAST_REF ,  3  elements ,  0x4  bytes 
Ptr32  to 

Bitfield  Pos  0,  3  Bits 
Uint4B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int4B 
Int  8B 

union  _LARGE_INTEGER  ,  4  elements  ,  0x8  bytes 

Uint4B 

Int  4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int4B 
Int  8B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 

Uint4B 

Int4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int 4B 
:  Int8B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 


75 


238 

243 

248 

253 

258 

263 

268 

273 

278 

283 

288 

293 


+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xld8  WriteTransf erCount 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xle0  OtherTransf erCount 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 
+0x000  QuadPart 
+0xle8  CommitChargeLimit 
+0xlec  Commit ChargePeak  : 

+0xlf0  Awelnfo  : 

+0xlf 4  SeAuditProcessCreat ion Inf o 
+0x000  ImageFileName 
+0xlf 8  Vm 

+0x000  LastTr imTime 
+0x000  LowPart 
+0x004  HighPart 
+0x000  u 

+0x000  LowPart 
+0x004  HighPart 


:  Uint4B 
:  Int4B 
Int8B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int  4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int4B 
Int8B 

union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int4B 

struct  ..unnamed  ,  2  elements  ,  0x8  bytes 
:  Uint4B 
:  Int4B 
:  Int8B 
Uint4B 
Uint4B 
Ptr32  to 

struct  _SE_ AUDIT_P ROC ESS _ CREATION. INFO ,  1  elements ,  0x4  bytes 
:  Ptr32  to 

struct  .MMSUPPORT ,  14  elements  ,  0x40  bytes 
:  union  _LARGE_INTEGER ,  4  elements ,  0x8  bytes 
Uint4B 
Int  4B 

struct  ..unnamed ,  2  elements ,  0x8  bytes 
:  Uint4B 
:  Int4B 


+0x000 

QuadPart 

:  Int8B 

+0x008  Flags  : 

struct  _MMS 

+0x000 

SessionSpace 

:  Bitfield 

+0x000 

Be ingTr immed 

:  Bitfield 

+0x000 

SessionLeader 

:  Bitfield 

+0x000 

Tr imHard 

:  Bitfield 

+0x000 

WorkingSetHard 

:  Bitfield 

+0x000 

AddressSpaceBei 

ngDeleted 

+0x000 

Available 

:  Bitfield 

+0x000 

AllowWorkingSet Ad j ustment  : 

+0x000 

MemoryPriority 

:  Bitfield 

+0x00c  PageFaultCount  : 

Uint4B 

+0x010  PeakWorkingSetSize 

:  Uint4B 

+0x014  WorkingSet Size 

Uint4B 

+0x018  MinimumWorkingSet Size  :  Uint4B 
+0x01c  MaximumWorkingSet Size  :  Uint4B 
+0x020  VmWorkingSetList  :  Ptr32  to 

+0x024  WorkingSetExpansionLinks  :  struct  _LIST_ENTRY ,  2  elements ,  0x8  bytes 
+0x000  Flink  :  Ptr32  to 

+0x004  Blink  :  Ptr32  to 

+0x02c  Claim  :  Uint4B 

+0x030  NextEst imat ionSlot  :  Uint4B 
+0x034  Next AgingSlot  :  Uint4B 

+0x038  Est imat edAvailable  :  Uint4B 
+0x03c  GrowthSinceLastEst imate  :  Uint4B 


+0x238 

LastFaultCount  : 

Uint 4B 

+0  x23c 

Mod if iedP age Count 

Uint4B 

+0x240 

NumberOfVads  : 

Uint 4B 

+0x244 

JobStatus  : 

Uint 4B 

+0x248 

Flags  : 

Uint4B 

+0x248 

CreateReport ed  : 

Bitfield  Pos  0 

76 


298 

303 

308 

313 

318 

323 

328 

333 

338 

343 

348 


+0x248  NoDebuglnher it 
+0x248  ProcessExit ing 
+0x248  ProcessDelete 
+0x248  Wow64SplitPages 
+0x248  VmDeleted 
+0x248  Out swapEnabled 
+0x248  Outswapped 
+0x248  ForkFailed 
+0x248  HasPhysicalVad 


itfield  Pos  1,  1  Bit 
itfield  Pos  2,  1  Bit 
itfield  Pos  3,  1  Bit 
itfield  Pos  4,  1  Bit 
itfield  Pos  5,  1  Bit 
itfield  Pos  6,  1  Bit 
itfield  Pos  7,  1  Bit 
itfield  Pos  8,  1  Bit 
itfield  Pos  9,  1  Bit 
+0x248  AddressSpacelnitialized  :  Bitfield  Pos  10,  2  Bits 
+0x248  SetTimerResolution  :  Bitfield  Pos  12,  1  Bit 
+0x248  BreakOnTerminat ion  :  Bitfield  Pos  13,  1  Bit 
+0x248  SessionCreationUnderway  :  Bitfield  Pos  14,  1  Bit 
+0x248  WriteWatch  :  Bitfield  Pos  15,  1  Bit 

+0x248  ProcessInSession  :  Bitfield  Pos  16,  1  Bit 

+0x248  OverrideAddressSpace  :  Bitfield  Pos  17,  1  Bit 
+0x248  HasAddressSpace  :  Bitfield  Pos  18,  1  Bit 
Bitfield  Pos  19,  1  Bit 
:  Bitfield  Pos  20,  1  Bit 
Bitfield  Pos  21,  1  Bit 

Bitfield  Pos  22,  1  Bit 

Bitfield  Pos  23,  1  Bit 

Bitfield  Pos  24,  1  Bit 

Bitfield  Pos  25,  5  Bits 

Bitfield  Pos  30,  1  Bit 

Bitfield  Pos  31,  1  Bit 

Int4B 
Uint2B 


+0x248  LaunchPref et ched 
+0x248  In j ect InpageErrors 
+0x248  VmTopDown 
+0x248  Unused3 
+0x248  Unused4 
+0x248  VdmAllowed 
+0x248  Unused 
+0x248  Unusedl 
+0x248  Unused2 
+0x24c  ExitStatus 
+0x250  NextPageColor 
+0x252  SubSystemMinorVersion  :  UChar 
+0x253  SubSystemMaj orVersion  :  UChar 
+0x252  SubSystemVersion  :  Uint2B 
+0x254  Prior ityClass  :  UChar 
+0x255  WorkingSet AcquiredUnsaf e  :  UC 
+0x258  Cookie  :  Uint4B 

kd>  dt  -b  -v  _PEB 
ntdll ! _PEB 

struct  _PEB  ,  65  elements  ,  0x210  bytes 


+0x000 

Inherit edAddressSpace  :  UChar 

+0x001 

ReadlmageFileExecOptions 

:  UChar 

+0x002 

BeingDebugged  : 

UChar 

+0x003 

SpareBool  : 

UChar 

+0x004 

Mutant  : 

Ptr32 

to 

+0x008 

ImagaBaseAddress  : 

Ptr32 

to 

+0  xOOc 

Ldr  : 

Ptr32 

to 

+0x010 

ProcessParamet ers 

Ptr32 

to 

+0x014 

SubSystemData  : 

Ptr32 

to 

+0x018 

RrocessHeap 

Ptr32 

to 

+0x01c 

FastPebLock  : 

Ptr32 

to 

+0x020 

FastPebLockRoutine 

:  Ptr32  to 

+0x024 

Fas tPebUnlockRout ine  :  Ptr32  to 

+0x028 

EnvironmentUpdateCount  : 

Uint4B 

+0x02c 

Kernel Cal lb ackTable 

:  Ptr32  to 

+0x030 

Syst emReserved  : 

(1  elements) 

+0x034 

AtlThunkSListPtr32 

:  Uint 4B 

+0x038 

FreeList  : 

Ptr32 

to 

+0  x03c 

TlsExpansionCounter 

:  Uint4B 

+0x040 

TlsBitmap  : 

Ptr32 

to 
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B.2  _ KPCR  Structure 


Listing  B.2:  Appendix2/kpcr.txt 

kd>  dt  _KPCR 
nt ! _KPCR 


+0x000 

NtTib  :  _NT_TIB 

4  +0x01c 

Self Per  :  Ptr32  _KPCR 

+0x020 

Prcb  :  Ptr32  _KPRCB 

+0x024 

Irql  :  UChar 

+0x028 

IRR  :  Uint4B 

+0x02c 

IrrActive  :  Uint4B 

9  +0x030 

IDR  :  Uint4B 

+0x034 

KdVersionBlock  Ptr32  Void 

+0x038 

IDT  :  Ptr32  .KIDTENTRY 

+0x03c 

GDT  :  Ptr32  .KGDTENTRY 

+0x040 

TSS  :  Ptr32  _KTSS 

14  +0x044 

MajorVersion  :  Uint2B 

+0x046 

HinorVersion  :  Uint2B 

+0x048 

SetMember  :  Uint4B 

+0x04c 

StallScaleFactor  :  Uint4B 

+0x050 

DebugActive  :  UChar 

19  +0x051 

Number  :  UChar 

+0x052 

SpareO  :  UChar 

+0x053 

SecondLevelCacheAssociat ivity  :  UChar 

+0x054 

VdmAlert  :  Uint4B 

+0x058 

KernelReserved  :  [14]  Uint4B 

24  +0x090 

SecondLevelCacheSize  Uint4B 

+0x094 

HalReserved  :  [16]  Uint4B 

+0x0d4 

InterruptMode  :  Uint4B 

+0x0d8 

Sparel  :  UChar 

+0x0dc 

KernelReserved2  :  [17]  Uint4B 

29  +0x120 

PrcbData  :  _KPRCB 

B.3 

DBGKD.GET.VERSION64  Structure 

1  kd>  dt 

Listing  B.3:  Appendix2/dbgkd.txt 

_DBGKD_GET_VERSI0N64 

nt ! _DBGKD_GET_VERSI0N64 


+0x000 

MajorVersion  :  Uint2B 

+0x002 

MinorVersion  :  Uint2B 

+0x004 

ProtocolVersion  :  Uint2B 

6  +0x006 

Flags  :  Uint2B 

+0x008 

MachineType  :  Uint2B 

+0x00a 

MaxPacket Type  :  UChar 

+0x00b 

MaxSt at eChange  :  UChar 

+0x00c 

MaxManipulate  :  UChar 

11  +0x00d 

Simulation  :  UChar 

+0x00e 

Unused  :  [1]  Uint2B 

+0x010 

KernBase  :  Uint8B 

+0x018 

PsLoadedModuleList  :  Uint8B 

+0x020 

DebuggerDat aList  :  Uint8B 
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5 

10 

15 

20 

25 

30 

35 

40 

45 

50 

55 


B.4  _KDDEBUGGER_DATA64  Structure 


typedef  struct 

Listing  B.4:  Appendix2/kddebuggerdata64.txt 

_KDDEBUGGER_DATA64 

i 


DBGKD.DEBUG. 

_DATA_HEADER64  Header; 

UL0NG64  KernBase; 

GCC_UL0NG64  BreakpointWithSt atus 
UL0NG64  SavedContext ; 

USHORT  ThCallbackStack ; 

USHDRT  NextCallback ; 

USHDRT  FramePointer ; 

USHORT  PaeEnabled : 1 ; 


GCC_UL0NG64 

KiCallUserMode  ; 

GCC_UL0NG64 

KeUserCallbackDispat cher  ; 

GCC_UL0NG64 

PsLoadedModuleList ; 

GCC_UL0NG64 

PsActiveProcessHead ; 

GCC_UL0NG64 

PspCidTable ; 

GCC_UL0NG64 

ExpSystemResourcesList ; 

GCC_UL0NG64 

ExpPagedPoolDe script or ; 

GCC_UL0NG64 

ExpNumberOf PagedPools ; 

GCC_UL0NG64 

KeTime Increment ; 

GCC_UL0NG64 

KeBugCheckCallbackListHead ; 

GCC_UL0NG64 

KiBugcheckData ; 

GCC_UL0NG64 

IopErrorLogListHead ; 

GCC_UL0NG64 

ObpRootDirect oryOb j ect ; 

GCC_UL0NG64 

ObpTypeOb j ectType ; 

GCC_UL0NG64 

MmSystemCacheStart ; 

GCC_UL0NG64 

MmSystemCacheEnd ; 

GCC_UL0NG64 

MmSystemCacheWs ; 

GCC_UL0NG64 

MmPfnDat abase ; 

GCC_UL0NG64 

MmSystemPtesStart ; 

GCC_UL0NG64 

MmSystemPt esEnd ; 

GCC_UL0NG64 

MmSubsect ionBase ; 

GCC_UL0NG64 

MmNumberOf PagingFiles ; 

GCC_UL0NG64 

MmLowestPhysicalPage ; 

GCC_UL0NG64 

MmHighestPhysicalPage ; 

GCC_UL0NG64 

MmNumberOf PhysicalPages ; 

GCC_UL0NG64 

MmMaximumNonPagedPoolInByt es ; 

GCC_UL0NG64 

MmNonPagedSystemStart ; 

GCC_UL0NG64 

MmNonPagedPoolStart ; 

GCC_UL0NG64 

MmNonPagedPoolEnd ; 

GCC_UL0NG64 

MmPagedPoolStart ; 

GCC_UL0NG64 

MmPagedPoolEnd ; 

GCC_UL0NG64 

MmPagedPoolInf ormation ; 

UL0NG64  MmPageSize 


GCC.UL0NG64 

MmSizeOf PagedPoolInBytes  ; 

GCC.UL0NG64 

MmTotalCommitLimit ; 

GCC.UL0NG64 

MmTotalCommittedPages ; 

GCC_UL0NG64 

MmSharedCommit ; 

GCC_UL0NG64 

MmDriverCommit ; 

GCC.UL0NG64 

MmProcessCommit ; 

GCC.UL0NG64 

MmPagedPoolCommit ; 

GCC.UL0NG64 

MmExt endedCommit ; 

GCC_UL0NG64 

MmZeroedPageListHead ; 

GCC_UL0NG64 

MmFreePageListHead ; 

GCC.UL0NG64 

MmStandbyPageListHead ; 

GCC.UL0NG64 

MmModif iedPageListHead; 
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60 

65 

70 

75 

80 

85 

90 

95 

100 

105 

110 

115 


GCC_UL0NG64  MmModif iedNoWrit ePageListHead ; 
GCC_UL0NG64  MmAvailablePages ; 

GCC_UL0NG64  MmResident AvailablePages ; 
GCC_UL0NG64  PoolTrackTable ; 

GCC_UL0NG64  NonPagedPoolDescr iptor ; 
GCC_UL0NG64  MmHighestUser Address ; 
GCC_UL0NG64  MmSystemRangeSt art ; 

GCC_UL0NG64  MmUserProbeAddress ; 

GCC_UL0NG64  KdPr int CircularBuf f er ; 
GCC_UL0NG64  KdPr int CircularBuf f erEnd ; 
GCC_UL0NG64  KdPrintWrit ePoint er ; 
GCC_UL0NG64  KdPr intRolloverCount ; 
GCC_UL0NG64  MmLoadedUser ImageList ; 
GCC_UL0NG64  NtBuildLab; 

GCC_UL0NG64  KiNormalSys t emCall ; 

GCC_UL0NG64  KiProcessorBlock ; 

GCC_UL0NG64  MmUnloadedDr ivers ; 

GCC_UL0NG64  MmLastUnloadedDri ver ; 
GCC_UL0NG64  MmTriageAct ionTaken ; 
GCC_UL0NG64  MmSpecialPoolTag ; 

GCC_UL0NG64  KernelVer if ier ; 

GCC_UL0NG64  MmVerif ierData ; 

GCC_UL0NG64  MmAllocat edNonPagedPool ; 
GCC_UL0NG64  MmPeakCommitment ; 

GCC_UL0NG64  MmTotalCommitLimitMaximum ; 
GCC_UL0NG64  CmNtCSDVersion ; 

GCC_UL0NG64  MmPhysicalMemoryBlock ; 
GCC_UL0NG64  MmSessionBase ; 

GCC_UL0NG64  MmSessionSize ; 

GCC_UL0NG64  MmSyst emParentTablePage ; 
GCC_UL0NG64  MmVirtualTranslationBase ; 
USHORT  Of f set KThreadNext Processor ; 

USHORT  Of f setKThreadTeb ; 

USHORT  Of f setKThreadKernelStack ; 

USHORT  Of f setKThreadlnit ialStack ; 

USHORT  Of f setKThreadApcProcess ; 

USHORT  Of f setKThreadState ; 

USHORT  Of f setKThreadBStore ; 

USHORT  Of f setKThreadBStoreLimit ; 

USHORT  SizeEProcess ; 

USHORT  Of f setEprocessPeb ; 

USHORT  Of f setEprocessParentCID ; 

USHORT  Of f setEprocessDirect oryTableBase ; 
USHORT  SizePrcb  ; 

USHORT  Of f setPr cbDpcRout ine  ; 

USHORT  Of f setPrcbCurrentThread ; 

USHORT  Of f setPrcbMhz ; 

USHORT  Of f setPr cbCpuType ; 

USHORT  Of f setPrcbVendorString ; 

USHORT  Of f setPrcbProcStateCont ext ; 

USHORT  Of  f  setPr cbNumber ; 

USHORT  SizeEThread; 

GCC.UL0NG64  KdPrintCircularBuf f erPtr ; 
GCC_UL0NG64  KdPrintBuf f erSize ; 

GCC_UL0NG64  KeLoaderBlock ; 

USHORT  SizePcr ; 

USHORT  Of f setPcrSelf Per ; 

USHORT  Of f setPcrCurrentPrcb ; 

USHORT  Of f setPcrCont ainedPrcb ; 

USHORT  Of f setPcrlnit ialBStore ; 
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USHORT 

Of f setPcrBSt oreLimit  ; 

USHORT 

OffsetPcrlnitialStack; 

USHORT 

Of f setPcrSt ackLimit  ; 

USHORT 

Of f setPr cbPcrPage  ; 

120  USHORT 

OffsetPrcbProcStateSpecialReg; 

USHORT 

GdtROCode ; 

USHORT 

GdtRODat a ; 

USHORT 

GdtROPcr ; 

USHORT 

GdtR3Code ; 

125  USHORT 

GdtR3Data ; 

USHORT 

GdtR3Teb ; 

USHORT 

GdtLdt ; 

USHORT 

GdtTss ; 

USHORT 

Gdt64R3CmCode ; 

130  USHORT 

Gdt64R3CmTeb ; 

GCC_UL0NG64  IopNumTr iageDumpDat aB locks 
GCC_UL0NG64  IopTriageDumpDataBlocks ; 
GCC_UL0NG64  Vf CrashDat aBlock ; 

>  KDDEBUGGER.DATA64 ,  * PKDDEBUGGER_DATA64 ; 


Appendix  C.  Building  the  Test  Platform 

This  appendix  gives  a  detailed  description  of  how  to  build  and  configure  the  Xen 
environment  as  described  in  this  thesis.  A  Dell  Latitude  D630  with  an  Intel  Core  2 
Duo  T7300  and  2  GB  of  memory  is  used  to  carry  out  experimentation. 

C.l  Install  Fedora  8 

1.  Install  Fedora  8  with  the  software  development  tools  option.  Also,  during  in¬ 
stallation  disable  ’IPv6’,  the  built-in  firewall  and  SELinux. 

2.  Add  /sbin  and  /usr/sbin  to  the  path  statement  in  ,bash_prohle  for  root  and 
the  configured  user  account. 

3.  Install  dev86  tools  from  a  root  terminal  with:  yum  install  dev86 

4.  Install  the  network  bridge  utilities  necessary  for  Xen  with: 
yum  install  bridge-utils 

5.  Disable  tls  with:  mv  /lib/tls  /lib/tls .  disabled 

6.  Remove  nag  about  tls  during  boot  with: 

echo  "hwcap  0  nosegneg"  >>  /etc/ld. so . conf 

7.  Update  the  dynamic  linker  with:  ldconf  ig 
C.2  Install  Xen  3.1.4 

1.  Download  the  Xen  3.1.4  source  code  from  the  www.xen.org  archives  at 
http://bits.xensource.eom/oss-xen/release/3.l.4/xen-3.l.4.tar.gz 

2.  Unpack  the  gzipped  tarball  with:  tar  xzf  xen-3 . 1 . 4 .  tar .  gz 

3.  Change  to  the  xen  directory  with:  cd  xen-3. 1 .4 

4.  Compile  Xen  with:  make  world 

This  will  take  some  time  and  you  must  be  connected  to  the  Internet  because 
the  Linux  2.6.18.8  kernel  is  downloaded. 

5.  Install  Xen  with:  make  install 
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6.  Execute  the  install  script  with:  . /install,  sh 


C.3  Configuring  Xen  Boot 

1.  Create  the  dependency  hie  for  the  2.6.18.8-xen  kernel  with: 

/sbin/depmod  2.6.18.8-xen 

2.  Create  the  initrd  image  for  2.6.18.8-xen  with: 

/sbin/mkinitrd  -v  -f  — with=aacraid  — with=sd_mod  — with=scsi_mod 
— with=tun  /boot/initrd-2 . 6 . 18 . 8-xen . irag  2.6.18.8-xen 

3.  To  the  hie  /boot/grub/menu.  1st  add  the  following: 
title  Xen  3.1.4  /  XenLinux  2.6.18.8 

root (hdO , 1) 

kernel  /xen-3.1.gz  console=vga  domO_mem=512M 

module  /vmlinux-2 . 6 . 18 . 8-xen  root=/dev/VolGroupOO/LogVolOO  \ 

ro  console=ttyO 

module  /initrd-2.6. 18. 8-xen. img 

The  boot  menu  will  now  contain  the  option  to  boot  the  Xen  kernel.  The  Xen 
kernel  does  not  support  the  video  card  in  the  Dell  D630  so  upon  initial  boot  the 
graphical  user  interface  will  fail  to  come  up.  The  operating  system  is  able  to  configure 
the  generic  VESA  driver  by  choosing  the  default  options  in  the  recovery  dialog.  The 
changes  are  made  permanently  in  the  /etc/Xll/xorg.  conf  hie  and  the  problem 
should  not  reappear. 
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C-4  Xen Access 

XenAccess  can  be  obtained  from  its  Google  code  repository  at 
http://xenaccess.googlecode.com/svn/trunk.  However,  this  version  does  not  incorpo¬ 
rate  my  modifications  which  were  made  to  revision  130.  This  version  can  be  checked- 
out  from  the  Fedora  8  command  line  using  the  command: 
svn  checkout  -r  130  <XenAccess  URL>  destination  folder> 

Requests  for  the  modified  source  code  used  in  this  research  should  be  directed  to  Dr. 
Barry  Mullins,  barry.mullins@afit.edu. 

1.  Unpack  the  gziped  tarball  with:  tar  xzf  filename. tar. gz 

2.  Change  to  the  libxa  directory. 

3.  Compile  the  library  with:  make 

4.  Install  the  library  with:  make  install 

In  the  source  code  for  this  research  modifications  were  made  to  many  library  hies,  but 
the  pagel.c  hie  in  the  xenaccess  directory  contains  the  bulk  of  the  additions  made 
by  the  author.  Additionally,  the  examples  folder  contains  the  test  programs. 

C.5  Creating  a  HVM  DomU  for  Xen 

This  section  describes  in  detail  how  to  create  a  virtual  machine  running  HVM 
for  use  with  Xen.  Creation  of  the  configuration  hie  and  virtual  disk  hies  is  the  same 
regardless  of  the  guest  OS  to  be  installed. 

1.  Creating  a  virtual  disk  hie  for  the  VM  named  imagename.img  and  10GB  in  size: 
dd  if=/dev/zero  of=imagename . img  bs=lk  seek=10240k  count=l 

2.  An  example  Xen  HVM  configuration  hie  can  be  found  in  /etc/xen/  after  in¬ 
stallation 
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